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EDITOR'S COMMENTS 



Welcome to 1993 and the next issue 
ofThe Computer Journal. I have been 
very busy on the magazine as usual. I 
think the direction and minor changes 
are starting to produce good results 
for myself and you the reader. Our 
writers have been grinding out plenty 
to read and ponder. I fear that some 
have even gone overboard with their 
efforts. 

Brad Rodriguez has part one of mov- 
ing Forth to other CPUs. This has 
been a hot topic among readers for 
some time and I think Brad will lay to 
rest all your questions on the topic. An 
on going problem for many new users 
of Forth has been making turnkey 
programs. Frank Sergeant shows you 
how to build your own application in 
Forth and make it into a turnkey ap- 
plication. 

TCJ's regular writers are here with 
their usual words of wisdom, or at 
least some good comments on their 
favorite topics. Rick Rodman fills in 
some gaps I had about tlie MINIX file 
system while showing you how he 
recovered from the dreaded curse. 

Charles Stafford helps all us novice 
Kaypro users decide which machine 
we really have. I for one am looking 
forward to fiiture articles of his, now 
that I know which version I want to 
buy at the next swap meet. Speaking 
of swap meets, Herb Johnson reviews 
a number of S-100 vendors and com- 
ments on the t>pe and quality of cards 
they produced. With all this informa- 
tion your next trip swapping should 
make sure you buy good classic sys- 



tems and leave the junk for the naive 
shopper. 

Our ever popular and resident guru of 
the ZCPR world, Jay Sage explains 
some fancy macro-ing and gives us 
some insights to why he uses ZMATE 
for everything. Here we all just thought 
ZMATE was a text editor, little did 
we know what power it really has. 
Thanks Jay for the peek in the door of 
your favorite program. 

TCJ CENTER FOLD? 

Yes, rC/has entered the big time with 
a center fold section. Well it may not 
be what first comes to your mind, but 
then if you are truly a hardware hacker 
at heart and a lover of old machines, 
our first center fold should warm you 
up some. It is a schematic of the origi- 
nal MPU-A CPU card fi-om IMSAl. 

This first item should help all you 
would be hardware people by bringing 
your collection of schematics up to 
date. That first date is 1975 however. 
Yup, this is an 18 year old CPU card. 
For those new people, life in the micro 
computing world started before PC 
Clones by many years. I have used 
these cards in the past and the sche- 
matic actually shows some corrections 
I made to resolve a problem. 

Check out the front and back pages of 
the center fold, as they contain a de- 
scription of the card. There is also 
some request for suggestions of sche- 
matics vou would like to see, but then 



you can read all that yourself in our 
new section, the Center Fold. 

I'M LATE, I'M LATE... 

If you haven't notice this issue is a bit 
late. I took my first vacation in two 
years over Christmas and have been 
trying to catch up ever since. The 
problem was also compounded by 
many of my wnters waiting till after 
Christmas to send their articles and 
not before as had been planned. Oh 
well, when things seem to go wrong, 
everything goes wrong. 

Issue number 60 should be closer to 
on time, but then what is on time 
around here. I try and get to the printer 
by the first week of the month listed 
(by Jan 10 for Jan/Feb issue). That 
should put it in tlie mail by the 20 to 
25 of January'. With those dates now 
laid out you can see I am about 4 
weeks behind. I should be able to gain 
one or two weeks each issue. In short, 
62 or 63 may be on time (if the print- 
ing press doesn't break AGAIN). 

No matter what delays happen, you 
should find the ever increasing pages 
of TCJ to your liking. If not, just write 
to the editor (oh, that's me...) and I 
will print what you think. Thanks and 
Enjoy, Bill Kibler, 
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READER to READER 



Letters to the Editor 

All Readers 

MINI Articles 



7 September 1992 

Hello Bill, 

When reading the 'new' TCJ issue #56 
(I received it on 3 September since it 
came with surface mail), I found some 
things to criticize and some room for 
improvements. So I will just list them up 
now (don't matter which order), and hope 
to get your reply somehow. 

1. Your article 'The Next Ten Years' 

I agree that sometimes going 'back to 
the roots' is necessary and good. But in 
some details, 1 cannot agree to your 
method of how to do that. Of course the 
know-how presented in the articles should 
be as portable as possible, but reducing 
all hardware projects to 'serial' projects 
or all software ideas to forth listings 
won't be the right way (and additionally 
is far too extreme). If you would indeed 
publish only (or almost only) 'serial 
hardware' and forth software, the maga- 
zine would lose very much (contents and 
readers). 

BTW, even if Forth as the language is 
very portable (and available for almost 
any computer), 1 don't think that it is 
ideal for demonstrating the how-to of 
programming. Instead, structured lan- 
guages as Pascal or IVIodula-2 are far 
more dedicated to that purpose, since 
they nearly exactly follow flowchart dia- 
grams, and explain themselves with their 
clear english commands. Additionally, 
there will be far more people being able 
to read Pascal or Modula sources of a 
strange author than there are with forth. 
(I also have some difficulties when try- 
ing to read a forth program.) So I think 
it is best to keep your eye on explaining 
algorithms (with flowcharts and/or Pas- 



cal/Modula sources), and not on strictly 
reducing every program to forth. 

Another thing that should be discussed 
is your statement about hardware and 
the components to use. When proclaim- 
ing TTL-only circuits, you should not 
forget that these normally need much 
times the board space and the power of 
the comparably higher integrated cir- 
cuits. Many of the newer designs would 
have been impossible without using 
modern VLSI components. With argu- 
ing even against PALs, you throw people 
back to the times where only TTL's were 
available. I think that one should freely 
use those components which are estab- 
lished and easily to get. Otherwise, you 
must also forbid using EPROMs (using 
diode matrices instead) or the good old 
Z80 (far too much integrated - replace it 
with TTL!). The EPROMs are a very 
good comparison to GALs. Since many 
people have EPROM programmers, you 
freely use those parts. Since more and 
more people are able to program GALs, 
we should use them too (but of course 
reduce it to few different types). 

I think I don't have to write much more 
about 'serial' hardware. Of course, some- 
times it makes much sense (and pro- 
vides portability). But you should not 
forget the large and very interesting sec- 
tor of peripherals which need some bus 
connection, i.e. my IDE-Interface. Al- 
though this one uses the ECB bus, the 
circuit idea is portable to any other 8-bit 
bus (but not to a serial port). 

One last sentence about 'going back to 
the roots'. If you write everything only 
for the absolute ('bloody') beginner, be 
aware that the more experienced readers 
will cancel their subscription, since they 
won't find anything new. I think that 



TCJ articles should be written for differ- 
ent readers with different skills, just as it 
is until now. BTW, some of the begin- 
ners will understand more if they look in 
the 'old' issues later. 

2. Missing information on how to reach 
someone 

In former TCJ issues, there was a short 
paragraph at each article giving some 
information about the author and how to 
reach him. This information is missing 
in the last issue. So this is why I have to 
fonvard this message via Jay Sage, and 
ask you for forwarding some details to 
some other authors. 

3. Something to forward to Tim 
McDonough 

That was a very nice article about input 
expansion. Perhaps one should have 
noticed that output expansion is possible 
exactly the same way, just with other 
shift registers. Concerning the software, 
the READS routine could be much easier: 



READS: MOV R0,#8 
READS 1: SETB CLOCK 
CLR CLOCK 
MOV C,DATA 
RLC A 



; counter 



; pulse clock 
move data into carry 
; shift into ACC 
DJNZ R0.READ8 ;loopforall8bits 
RET ; return with data in ACC 



When the 8031 has such a wonderful 
Boolean processor, why not use it? This 
speeds up the routine somewhat (and 
since serial input is quite slow compared 
to parallel ports, reduces this difference). 
I didn't look at his software in detail, I 
just saw that routine when moving on to 
the next page. 
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4. Your comment on my article 

I read the complete TCJ very carefully 
but did not find anything that would give 
your comment some sense. What about 
the Novix system and your problems 
connecting an IDE hard disk to it? 

5. New IDE-Interface version available 

Meanwhile, I improved the IDE inter- 
face circuit and PCB layout due to some 
critical timing details. The new version 
is available now. (There are no boards of 
the old version ever come into the USA.) 

6. Real Computing 

When reading Rick's article this time, I 
hardly missed any statement about Co- 
herent (actual version 4.0), which seems 
to be a very good OS for the UNIX 
beginner. The rest of the article is very 
informative and interesting. I hope that 
it will be continued (and will offer some 
information about Coherent). 

7. Article Jumping 

I am very surprised! Some time ago I 
wrote to Chris McEwen about the ar- 
ticle-hopping within TCJ. I pointed out 
that the articles should be printed just 
. one after another, to avoid that unneces- 
sary harassment. He just answered, that's 
american typesetting and not european. 
But now I find that the 'new' TCJ has its 
articles just one after another. VERY 
GREAT ADVANTAGE! 

8. Subscription Expiry 

When I wrote my last article for TCJ 
(about the CPU280), Chris gave me some 
kind of free subscription for a limited 
time instead of money. I agreed to that, 
since it simplifies everything (we don't 
have to transfer money overseas two 
times). Unfortunately, the subscription 
expiry printed on the address label did 
not change with my new article. I think 
that is caused by the changes and you 
will surely correct it with the next issue. 

9. Another article in TCJ ? 

Meanwhile, the text and graphics termi- 
nal mentioned in my CPU280 article is 



finished and running. So this could be 
the stuff for another 'bus connected pe- 
ripheral' article. It is also a EuroCard 
with its own Z80 processor and a paral- 
lel bus interface (for the host it appears 
just like a Z80-SIO with one data port 
and one status port). 

For your answer (and further correspon- 
dence) you may reach me by e-mail (best) 
or by fax (2nd best) as written above. 

Greetings, Tilmann 

Thanks Tilmann for the long letter. Al- 
though I didn 't get it until late Novem- 
ber, your comments are always welcome. 
I have updated your subscription and 
you should receive them much faster 
than this response. 

As to your comments, I had no idea what 
' 'BTW 'means untilJay told me it stands 
for ' 'by the way ' '. I had looked in a few 
dictionaries and found nothing. So when 
it comes to ' 'BTW' ' I guess I am a be- 
ginner. 

I am passing on your comments to Tim 
McDonough. Thanks for the other ideas. 
As to the problems with the ' 'Next Ten 
Years ' ' article, that was mostly a dead- 
line problem. That was in fact the first 
draft which never got updated as would 
be normal. 1 am trying to get more time 
to work on things and hopefully starting 
in January this will be the case. 

On my going back to the roots, as far as 
TCJ is concerned, is not giving up on 
our past or NEW readers. For TCJ to 
continue we must add new readers every 
month. The only way we can do this is to 
make sure all readers can understand 
our articles. That means taking the time 
at the onset of an article to review all 
basic information our readers would 
need to know to be able to complete the 
project. The only option to NOT provid- 
ing beginning information as has been 
the case, is to charge $50 a year sub- 
scription fees for the two or three hun- 
dred readers who could understand the 
advanced material. Not a choice I would 
like to make. 

Supporting beginners is not teaching 
fundamentals, but just making sure we 



explain all our terms (like BTW and yes 
J apologize for not explaining SOG, 
means Semi Official Get-together and 
came from Micro Cornucopia's editor 
Dave Thompson) and tell them where to 
seek more information if they have not 
yet reached the needed level of knowl- 
edge or experience. Check out Jay 's col- 
umn this time and notice his treatment of 
explaining what he covered in back is- 
sues. Jay 's review only took one or two 
paragraphs, but lets the reader know 
what they will find in those past issues, 
plus he reviews it a little now so they 
don 't have to read the articles again 
before understanding this article. 

Experience is one area that most begin- 
ners usually lack. A typical question I 
get is how do you get that experience. 
Hopefully our articles will provide 
projects that the reader can use to ac- 
quire their needed experience. Giving 
enough information just helps make sure 
this is a positive experience for them. 
Should they not have a positive experi- 
ence it will not be just the project which 
doesn 't get done, it will be TCJ that 
stops being read by them (as has been 
the case in the past). 

My position on PALs is quite simple, I 
hate them. I spent too many years re- 
placing them and throwing boards away 
because no replacements were available 
after the supplier went out of business. 
Now I agree that PALs are considerably 
better than they were, and most vendors 
are starting to supply some information 
so you could program themyourself but 
that concept is still not the normal situ- 
ation. I rather doubt that more than 25% 
of our readers have access to PAL pro- 
gramming equipment. With that in mind, 
projects that only give you the PAL code 
and not the equivalent circuit it replaces, 
makes it out of reach to 75% of our 
readers. Sure we can have them sup- 
plied by you when they buy your board, 
but that prevents the junk box builder 
from making his or her one of a kind 
project. 

My other dislike of ' 'only ' ' providing 
PAL design information is the lack of 
education. We now use field program- 
mable gate arrays (at my work) and the 
designer programs them using regular 
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discrete logic cells that are arranged or 
tied together ( in a $3000 software pro- 
gram ) much as if you used them sepa- 
rately. Thus the designer must know how 
to do regular logic design and not just 
some logic description for the PAL pro- 
grammer. What our articles are suppose 
to do is teach the reader how to do this 
project and others like it. Showing them 
how and why you have this logic or that 
is what they want to know. Showing them 
next how that logic gets defined into 
several logic statements for the PAL 
programmer then is much more educa- 
tional. 

What I have proposed is our articles be 
structured. Make sure we explain what 
the project is suppose to do. Review the 
fundamentals needed and where the 
reader may turn to gain the lacking 
knowledge or skills. Do the project much 
as we have always done them, but give 
them both a non-PAL schematic and the 
smaller PAL options. Follow up by pro- 
viding how you can be reached, where 
parts are available, and any alternative 
projects to the one presented. 

On software, I am not a Forth only pro- 
grammer. My favorite language is as- 
sembly. My main concern is that "C" 
has grown way out of proportion to the 
claims laid on it. But both of those state- 
ments detract from the main idea which 
you so well expressed. We want the read- 
ers to see the steps needed in software as 
we do in hardware. Yes, I agree that 
Pascal might be better, but often it is too 
strict for hardware level programming. 
Pseudo style language flow charting is 
best, and lets the programmer do it in 
their favorite language. Hike Forth only 
because it is truly the only platform in- 
dependent language currently available. 
I have and can still write programs that 
can be used on many different CPU ar- 
chitectures without any changes. Simply 
load the Forth screens and run the pro- 
gram. That is all you need do, very 
simple, anyone can use them. My direc- 
tion for TCJ is to try and make all our 
software projects that simple for the 
reader. 

That brings me to the IDE article which 
many of our readers were glad to see but 
felt a bit short changed. I keep getting 



asked where the sofhi'are part of the 
project is. A Ithough you did a very good 
job of pointing out the hard^'are side of 
the interface, there wasn 't any help in 
writing code to talk to the new device (a 
point I mis.'ied when 1 wrote the intro- 
duction). What is needed is information 
.such as: what commands are needed 
and used, what are the responses you 
get back from the interface, what data 
structures are needed if any, are there 
any timing problems I must be aware of 
and lastly is the data transferred byte at 
a time, word at a time, or must there be 
some form of DMA transfer? I must admit 
to not getting all publications, bull have 
not seen anything in print about IDE 
interfaces. So what 1 guess we need is a 
comprehensive review of IDE interface 
standards. We also need to know if the 
schematic is still correct or did you make 
changes to it to resolve the speed prob- 
lem you mention. 

On UNIX and Coherent, I have had sev- 
eral conversations with Rick Rodman 
and we are planning many articles that 
review the advantages and features that 
each implementation provides. Rick is 
always open to specific questions, so 
please pass any questions along that 
you might have to him. Which is another 
area you were concerned about. I think 
I did miss a few ' 'biographies ' ' of writ- 
ers, but it has and always will be our 
main concern to provide the reader with 
a means of contacting the writer di- 
rectly. Lastly your being on Internet and 
my not being there as well. GENIE now 
has a Internet serx'ice and I will be on it 
by the time you get this. It will take some 
time to get up to speed on using the 
service, but it should cut out the three 
month turnaround on your questions. 

Thanks again. Bill Kibler. 



Dear mr. Kibler: 

In response to the article in TCJ issue 
no. 58 concerning moving the reset but- 
ton on Kaypro computers, the article 
describes exactly what I have done many 
times on my own Kaypro computers and 
also for other members of my club, the 
Data Bytes User's Group of St. Louis, 
formerly The St. Louis Kaypro Users 



Group. The procedure is great but stops 
just short of one step I've taken. 

On those Ka>T)ro CP/M computers which 
have a cooling fan. the fan inhales air 
from the outside and pressurizes the case 
somewhat causing an outward flow of 
air through the many slots. I've found it 
desirable to close the hole from which 
the reset switch was removed so as not to 
unbalance the air flow, especially, in the 
older Kaypro 10s, with a full height hard 
drives, where there is a lot of heat gen- 
erated. 

Initially, I put a piece of duct tape over 
the hole. Later, 1 found metal hole plugs 
to close the hole. After my source of 
plugs ran out, I found a functional dupli- 
cate of the reset switch, a SPST normally 
off push button switch, at the local Radio 
Shack. This switch had the advantage of 
using a 5/16" diameter hole, which 
helped since I do not have a 17/32" to 9/ 
16" diameter drill bit to make a hole like 
Kaypro used. I ran a pair of 24 gauge 
wires from the new switch to the origi- 
nal Kaj-pro reset switch and soldered 
them in place at both ends in parallel to 
the original switch, and insulated the 
soldered connections at the front end 
with clear silicon sealer. Makes a dandy 
strain relief, too. 

I'm writing this on a modified Kaypro 
10 with TurboROM, NZ-COM, and two 
20 megabyte hard drives, which works 
very nicely with this switch arrangement. 
The original Kaypro switch makes a 
dandy hole plug, too! 

Incidentally, related to heat, I've 
resoldered the main connector joints on 
the power supply of each Kaypro I've 
worked on to PREVENT future solder 
problems. I've seen some in which the 
solder was literally blasted out of the 
1 lOV pins on the power supply board 
(the bottom two). 

Yours very truly. 

Bob Rosenfeld 

DBUG NEWS Editor 

Data Bytes User's Group of St. Louis 

Tho.se are .some good ideas and com- 
ments Dob. Charles Stafford is planning 
a power .supply article soon, seems the 
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supplies are underrated and PC sup- 
plies can be used very cheaply. I take 
great joy in knowing that you are still 
using your Kaypro and wonder what was 
involved in putting two 20MB drives on 
it. 

I mentioned the taping the vents to 
Charles and he indicated that adding 
larger fans might be better all the way 
around. I think we will hear more about 
cooling those beasts at a later date. 
Lastly let me remind you that I would 
like to get your newsletter and can give 
discounts to your members if they sub- 
scribe as a group. These are a few of the 
NEW options available now that I have 
increased the rates. I cover those op- 
tions elsewhere in the magazine. 

Thanks for the letter Bob. 

Mr. Kibler 

Enclosed is my check for two year sub- 
scription. 

I began building computers back in 1978 
when a physics student of mine sug- 
gested that I might be interested in a EE 
extension course at the local university 
(Univ of MO.) As a result of the course 
I put together a microcomputer based on 
, the National SC/MP microprocessor ....it 
had a total of 256 bytes of memory. 

After that experience I worked as a pro- 
grammer/system analyst for a local envi- 
rormiental engineering firm that used 
Cromemco computers in their data ac- 
quisition systems that took weather and 
pollution data....l stopped working for 
the firm about 10 years ago. 1 still have 
two complete working Z2D Cromemco 
systems in my basement with all sorts of 
software and accessory boards. 

Much to my wifes chagrin, I have be- 
come a collector of old computers. Along 
with the Cromemco machines I also have 
a KIM computer, an old working Com- 
modore 64 computer and about six IBM 
clones ( use them as data collectors in 
my high school physics course) plus two 
IBM XT's Fve been quite lucky at 



garage sales and auctions getting most 
of the old machines for very little... 

Well that's my story. 

Cordially yours 
Lawrence LHote 
Columbia, MO 

You will be glad to know Lawrence, that 
my S-100 system, which still gets used 
occasionally, is mostly Cromemco. Herb 
Johnson our S-100 person, has a 
CROMIX system for sale (Cromemco 's 
version of Unix) which I think about 
getting from him (used one at previous 
job). My spouse also likes picking on my 
"classic" collection of computers, but 
then collectors have always been treated 
that way until their collectible junk be- 
comes valuable antiques. If TCJ goes 
the way I plan, it will not be long before 
these truly classic systems start being 
.sought after and enjoyed by more than a 
few users like us. 

Thanks for the subscription. Bill. 

Gentlemen: 

Thanks for sending me the sample issue 
of TCJ, No. 57. I'd like to subscribe for 
two years beginning with No. 58. 

I'm using mostly CP/M computers, in- 
cluding Kaypro 2X ( I think it is) and 10, 
plus the old North Star; but in addition 
I have a Texas Instruments Professional 
which does pretty well with some of the 
MS-DOS software. I am interested in 
installing ZCPR3, but don't want to do 
so until I have the source code for the 
utility programs that form an important 
part of the system. It seems to me that 
some of the bulletin boards had the whole 
package years ago. I have a lot of the 
material on the various components of 
the control program itself but not on the 
utilities for directories, file manipula- 
tion, etc. I understand that a program 
needs to be tailored for ZCPR3 in order 
to make proper use of it and I'd like to 
see what's involved. Ultimately, as 
Humpty Dumpty said, it's a question of 
who is the master, and I want to be the 
master of my system. 

If you know any BB's or libraries that 
have all the source code, please let me 



know. I am glad to see that you're offer- 
ing support to us antiquarians who are 
interested in older machines. Keep up 
the good work! 

Sincerely yours, 
Fred Ordway 

Thanks for the support Fred. Well the 
person who has all the answers about 
ZCPR is Jay Sage. Try his bulletin board 
listed on his ad (Sage Microsystems) 
inside the front cover. You might try 
GENIE'S CPM section (or JAY. SAGE), 
it has plenty of source code to many of 
the utilities. We also have some of the 
original source in the Micro-C disk li- 
brary (22 & 23), but J am not sure if it 
is all the utilities your interested in. You 
have however hit on one of the main 
selling points of using the old systems 
(we have all the source code for the 
programs, including the operating sys- 
tem). I am planning on setting up a new 
section for what and where you can find 
the source code for the many programs 
our u.ser might need for using and up- 
grading their systems I have always been 
after BIOS code, for without it you can 
not add new devices very well. The util- 
ity code is just as important as the BIOS 
but sadly more often overlooked. Please 
keep me posted as to what you found and 
where. 

Thanks again Freed. SDK, 

Dear Mr. Kibler 

I have enjoyed your comments in TCJ 
ever since you have taken over editorship, 
especially in your replies in REARER to 
READER. 

I would like to add my perspective on 
things: 

I am looking for a replacement or the 
information that was presented in early 
BYTE/Creative Computing/Micro/ 
Dr.Dobbs. I read your first Editor's 
Comments and it resonated. I would 
like to influence you to make only two 
changes over your comments : 1) open 
up hardware articles to programmable 
logical devices if the article author speci- 
fies how the prospective builder could 
obtain the programmed devices; 2) pro- 
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vide a quantitative definitia of what a 
rare or expensive component is. 

On the programmable devices, I offer to 
help anyone program any memory de- 
vice, and some PAL, GAL, PEEL and 
PLD. So any programmable devices 
should be allowed in hardware articles. 
If this becomes important, I will write 
another letter giving a device list and 
conditions. 

On the rare and expensive components, 
I would like to suggest that a popular 
article use only components that can be 
found in Radio Shack, from Jameco, JDR, 
Digi-Key and Moser. A popular hard- 
ware article would be an article about 
hardware to solve a useful or fun func- 
tion using an embedded computer. Oc- 
casionally a special hardware project is 
called for, the task can only be solved 
well with a special component, many 
readers would find the approach inter- 
esting, but few would actually build the 
unit. In this case I would like to suggest 
line drawing at the author locating at 
least 200 of the unique components and 
making the address of this location avail- 
able in the article. I would further like to 
draw the line at $100 for a component 
and $250 for a hardware project. 

I would like a hardware to software ar- 
ticle ratio of 50/50. 

I am seeking a magazine where people 
of interest similar to my own can meet. 
Right now I subscribe to Circuit Cellar, 
Midnight Engineering, TCJ and Atari 
User. If I dropped one of these other 
magazines I would have more money for 
a TCJ subscription. In the past I have 
found Circuit Cellar the magazine the 
most worth keeping, even though I don't 
like it. 

I will tiy quickly to describe my inter- 
ests: 

Assembly language program: 6502, 
6809, 68HC11, 65C816. HOL program: 
BASIC, FORTH, C (in that order of 
preference). I like to build hardware. My 
preference is a 65C816 based system 
using 65C51 and 65C22 for I/O. Found 
that the single board 68HC11 is the fast- 
est and lowest cost solution to embedded 



control (also with plenty of free software 
tools). 

Would like to read software articles based 
on the languages I use. Would like to 
read hardware articles based on the pro- 
cessors I like. 

I would like to read or write an article on 
how to use (hardware and software) a 
XT clone keyboard to any of the proces- 
sors I am interested in, as that is the best 
and cheapest input device. I would like 
to read lots of articles on how to connect 
output devices to the processors I am 
interested in. 

Would like TCJ to set publication cost to 
subscription rate such that it was 100% 
subscription supported. It has broken 
my heart too many times to see a well 
loved magazine fold when the advertis- 
ing withdrew. Tell us how many pages 
of text and schematic you can mail to us 
per year for how many dollars per year 
and let us make recommendations. 

Suggest that you publish a ' 'How to Write 
for TCJ" include style, format, word 
processors supported, CAD formats sup- 
ported and desired type of articles. There 
is no reason that all submissions can not 
come "camera ready". 

Joseph Ennis 
Valparaiso Florida 

Well Joseph that was a great letter that 
reinforces many of the ideas I have been 
talking about lately. On cost of publish- 
ing, I hcn'e adjusted the rates closer to 
my actual costs, and separated out the 
extra mailing costs our overseas read- 
ers pay. Mailing cost went up, but our 
rates had stayed the same, but now all 
that has changed. 

TCJ has never had and may never be a 
advertiser supported magazine. 
ELEKTOR, just folded US publishing 
with 10,000 readers, because the profit 
margin was too small. Some day I hope 
TCJ has a profit margin to be concerned 
about. WE are and always will be ori- 
ented to users, and as a classic support 
magazine (no vendors provide support), 
that means no advertisers will be inter- 
ested in us either. If you look at PC 



magazines (IBAT clones that is), they only 
sell new items. New items are not what 
are readers are interested in. 

The PALs and all are still not my favor- 
ite component. I appreciate your offer to 
burn PAL 's, hut that could be a bit tricky 
for someone in China, or India. TCJ 's 
readership is far outside the US borders 
and as such keeps me from endorsing a 
PALs only design. I consider the best 
approach is one that uses regular TTL 
logic and then shows how that logic can 
be replaced with a PAL. We leave the 
choice and option up to the reader and 
not the writer. Remember, you had to 
figure the design out first, as if you could 
use those TTL devices before you pro- 
grammed that PAL. Why not pass along 
that design and thinking to our readers 
as well as the other aspects of the project 
(much more educational). 

Rare and expensive components to me, 
are ones not available in junk boxes. 
Now many of our readers have access to 
very fancy junk boxes, but most have to 
remove components from old S-100 
boards or game machines. That means 
at least ten year old techno logy or simple 
TTL devices. Your dollar limits actually 
are a bit high for me, maybe half those 
values would be better. I will have to 
wait and see what our other readers 
have to say before I place judgment on 
that position. A reason for that is a ten 
dollar component may become a forty 
dollar one in South America. 

I hate to keep repeating myself, but I feel 
Americans have lost sight of how much 
freedom of access we have to cheap 
components and especially the habit of 
using the latest high technology solu- 
tion. I have received comments about 
using Forth (which I noted you use), but 
in Russia where big fast computers are 
a rarity, Forth is the number one lan- 
guage. Many countries still do not have 
the computer systems we take for gran- 
ite. 

Don 't hesitate to write those articles 
about using PC Clone keyboards, I think 
many of the PC items are just the ticket 
to keeping alive classic systems at mini- 
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mum cost. Thanks again Joesph for your 
comments. Bill Kibler. 

DEAR BILL, 

I have been a subscriber of COMPUTER 
JOURNAL since its inception and enjoy 
reading most of the articles. Due to cir- 
cumstances beyond my control the last 
few years I have been unable to do very 
much in the way of experimenting with 
the various things that can be done with 
computers. Consequently my equipment 
is rather ancient and I have not added to 
the systems that I use. Now that deter- 
rent has been eliminated so perhaps I 
can get on with the playing. 

The computers here consist of an H89A 
that I assembled in 1980 or 1981; two 
Z90s and a couple or three years ago I 
bought the Ampro Little Board 100 that 
Art Carlson had. All systems are opera- 
tioiial and have 4 floppy drives and the 
Ampro has a lOM hard drive. 

I have no idea how many you have on 
your subscription list but the printing of 
the labels could probably be done here 
and at least for awhile and it would cost 
you nothing. If that would interest you 
send me a list and I'll make you a sample. 
The printer here is a Diablo 630. 

The occupation here during my working 
life was printing - both newspaper and 
state printing plant. Therefore typo- 
graphical errors and grammatical errors 
are quite noticeable. I do not wish to be 
overly critical but hope there is more 
time to proofread the copy in the Mure. 

I hope publication of the COMPUTER 
JOURNAL continues for a long time. 

Sincerely, 

MARVIN F. ROBERTS 

TOPEKA KS 

Thanks Mar\>in for the offer of doing 
labels. The problem 1 have discovered is 
not printing the labels, but doing all the 
bookkeeping and paper work. I discov- 
ered problems with my mailing program 
when 1 received a Christmas gift sub- 
scription request. How was I to charge 
and keep track of the payer and the 
receiver of the gift. With the addition of 



Micro-C disks, the many different mail- 
ing cost, and some sales tax collection 
and reporting needs, it has become ap- 
parent that a full charge bookkeeping 
program (with mailing list option) is 
needed. About the only way someone 
else could help me with the labels would 
be if they took over the 1-800 number, 
credit card processing, back issues and 
disk coping and mailing, banking mail- 
in subscriptions, and just sent me the 
labels after telling me how many to print. 
Unfortunately it would also have to be 
done free, as we are not breaking even 
now and could not afford to pay anyone 
for those ser\>ices. I also forgot to men- 
tion they should also be available for 
answering the phone during normal 
working hours, have knowledge of clas- 
sic computers, and use computers. 

As you can guess I don 't really expect 
any help in this area, it is just another 
situation in which an improved program 
will make things easier and faster and 
over time become less of a problem. 
Finding time to set up the program how- 
ever has been the real problem. 

I hope your getting back into computing 
is not buying a PC clone! Your past 
knowledge with older machines would 
certainly make you an unhappy pc user. 
I know Art will also be glad to read that 
you are still using the system you got 
from him. Keep up the good work and let 
us know what that new system becomes. 
BDK. 

Dear Bill. 

Received issue #58. Thank you. I want 
TCJ to succeed. Please don't worry overly 
about what Joseph Mortensen said. I saw 
the typos, etc. and I felt the content of 
TCJ made up for them. If I send in 
articles, what format is readable by you? 
I prefer 3.5 inch Macintosh or 1.4M 3.5 
inch IBM. 

In response to the letter in #58 from 
Christopher Browne: I use New Micro 
Computers of various sizes (the ones 
with embedded forth language) and I 
think they are great. I have written soft- 
ware modules for X-10, i2c. stepper 
motors, cardreader emulators, 
cardreaders, ADB support, multi-task- 



ing, etc. I will provide details on these 
items to interested parties. I hope to 
publish this info in TCJ if Bill is inter- 
ested. 

Gus Calabrese 
Prsident WFT. 

Thanks for the good words here and in 
Forth Dimensions I saw your letter to 
the editor in which you mentioned us, we 
need all the good words we can get. 
Currently I use PC Clone based system 
for my TCJ work. I have plenty of other 
systems (most CP/M formats supported, 
including 8 inch) but have not broken 
down and bought a Macintosh yet (did 
buy an Magic Sac for my Atari, but alas 
it doesn 't work). Please write an article 
on using the New Micros system, we get 
plenty ofrequests for just what you have 
done. Drop me a note before you start 
on the articles, so I can make sure you 
are not doing the same project one of 
our other writers is working on. Thanks 
again Gus. Bill. 



Admissions to TCJ 

To submit articles or letters to TCJ 
please send them to the below ad- 
dress. I can be reached alternately, 
by means of GEnie or CompuServe 
as listed below. 

TCJ is always looking for new 
writers and we accept most manu- 
scripts that help our readers up- 
date and improve their computing 
skills and systems. We especially 
look for low tech solutions to com- 
plex problems. TCJ also supports 
systems no longer supported by 
manufacturers or other magazines. 
Some of these systems are : Z80 
based S-100, Kaypros, Xerox 820, 
and other systems running CP/M. 
We also support the 68xx(x) series 
of machines made by GIMIX, 
S WTP, and those systems that run 
Flex or 0S9. 

TCJ 

P.O. Box 535 

Lincoln, CA 95648-0535 

GENIE B.Kibler 
CompuServe 71563,2243 
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The Z-System Corner 

By Jay Sage 



Regular Feature 

ZCPR Support 

Advanced ZMATE 



Advanced Applications of ZMATE 

Autoexec Macro for Automating 
ZMATE 

ZMATE is a very flexible, powerful, and 
configurable editor (and even word pro- 
cessor), but it can actually do far more 
than meets the eye, even the eye of an 
experienced user. Over the years I have 
continued to develop more and more 
productive uses for it. On the one hand, 
I have learned to automate the operation 
of ZMATE itself; on the other, I have 
learned how to use ZMATE as a tool to 
automate other operations. In this col- 
umn and several subsequent columns I 
would like to share some of these tech- 
niques with you. 

Relatively few people have taken advan- 
tage of the availability of ZMATE. The 
reason for this, I think, is that most 
people already had an editor or word 
processor that they were comfortable 
with, and they saw no reason to learn to 
use a new one. I hope to convince some 
of you here that ZMATE can add a whole 
new dimension to what you can accom- 
plish on your computer, and that it is 
worth the effort to learn to use it. 

The discussion here will also illustrate a 
more general principle, one that con- 
stantly motivates Z-System develop- 
ments. When software supports a flex- 
ible, generalized interface, it can find 
uses beyond anything the author origi- 
nally envisioned. I am sure that Michael 
Aronson (MA7E stands for Michael 
Aronson's Text Editor) would be amazed 
to see how I use MATE - but he would 
not be amazed to see that I am using it 
in new ways. He put in all the hooks and 
functions to make that possible. You 
may have other programs that provide 



powerful interfaces, and you may be able 
to invent radically new applications for 
them. 

Before getting down to business, 1 would 
like to mention that Gene Pizzetta and 
Howard Goldstein teamed up to clean up 
the ZMATE code. Bridger Mitchell did 
a fabulous job of disassembling PMATE 
(Mike Aronson could no longer find the 
source code!) and then adding a number 
of nice features, such as tvvo-window 
operation. However, a number of old 
bugs remained, and a fair number of 
new ones got added. In addition, Gene 
and Howard have made it possible to set 
most of ZMATE's configuration options 
using Al Hawley's ZCNFG tool. 

If you purchased ZMATE from Sage 
Microsystems East, you may get an up- 
date by sending back your original dis- 
kette in a mailer that can be reused to 
return the diskette to you. Include a 
return-address mailing label and enough 
stamps or money to cover the postage. If 
you are out of the U.S. and have no way 
to supply stamps or money, SME will 
cover the cost. 

In issues 46 and 47 of TCJ I described 
ZMATE in considerable detail. The first 
column covered its underlying principles 
of operation, such as tlie totally user- 
controlled binding of key sequences with 
characters and functions and the fact 
that ZMATE is really an interpreted 
programming language, like BASIC, but 
with command primitives designed for 
text processing. It pointed out that 
ZMATE programs ~ or macros, as they 
are generally called ~ can be run in 
several ways. They can be entered manu- 
ally and e.xecuted from ZMATE's com- 
mand line; they can be stored in what is 
called the Permanent Macro Area or 



PMA; and they can be stored and ex- 
ecuted from any of the 10 numbered 
editing buffers (0 through 9). 

In issue 47 I gave a broad overview of 
ZMATE's macro language. In this col- 
umn you are going to see some substan- 
Ual examples. If you have and use 
ZMATE, you might want to study them 
in detail; if not, by skimming the com- 
ments you will get an impression of how 
ZMATE operates. 



The ZMATE Autoexec Macro 

The ZMATE permanent macro area 
contains definitions for a number of 
macros that have single-letter names. 
These macros can be invoked in other 
macros entered on ZMATE's command 
line or executed from ZMATE's text 
editing buffers. You'll see some ex- 
amples later. Each permanent macro 
definition begins with a control-X char- 
acter followed by the name of the macro, 
and it ends either with the beginning of 
the next definition or the end of the 
PMA. 

There can also be one special definition, 
a macro that executes automatically 
whenever ZMATE starts up. I call it the 
"autoexec" macro, since it is like the 
AUTOEXEC.BAT file that runs at boot- 
up on a DOS machine. (I must have 
given it that name before NZCOM came 
along; otherwise I would have called it a 
"startup" macro.) This macro must be 
the first definition in the PMA, and it 
must start with a control-S instead of 
control-X followed by a name. 

If no autoexec macro is defined, ZMATE 
interprets command-line arguments as 



The Computer Journal / #59 



the names of files to open. The first 
token is the name of the input file to edit. 
If a second file is named (and the first 
file already exists), then it is used as the 
name of the output file. Thus the com- 
mand line 

EDIT MYFILE 

opens an existing file or creates a new 
file called MYFILE. The command line 

EDIT THISFILE THATFILE 

opens an existing file, THISFILE, (you 
get an error message if it does not exist), 
and writes the edited contents to a new 
file, THATFILE (you get an error mes- 
sage if it already exists). 



Making a Dedicated Tool 

The autoexec macro allows one to turn 
ZMATE into a dedicated text-process- 
ing tool. For example, let's suppose that 
we want a tool that will convert a text 
file entirely to upper case. We could 
load the macro shown in Listing 1 into 
an editing buffer; store it into the PMA 
using the command QMC (Q-Macro- 
Copy); and then clone a new version of 
ZMATE using the XD (file Duplicate) 
command. For example, XDupcase 
would create a file UPCASE.COM that 
would run the macro in Listing 1 as soon 
as it was invoked. We might use our 
new tool as in the following examples: 

A>upcase thisfile convert text in the file 

THISFILE to upper case 

A>upcase Ic uc convert text in the file 

LC to upper case and store 
it in the file UC 

Of course, this is not a terribly practical 
example. ZMATE macros, being inter- 
preted, do not run very fast, especially 
when, as here, every single character has 
to be processed one-by-one. This simple 
example could be implemented rather 
easily in any programming language, 
such as BASIC or PASCAL. Using the 
SYSLIB assembly-language library rou- 
tines, we could even do it quite easily in 
assembly language. However, more com- 
plex editing tasks might be so hard to 
write in other languages, that we would 



not even attempt to do so. Operations 
that make use of ZMATE 's more pow- 
erful macro commands, such as search- 
ing for text, can run quite fast. 



A Generalized Autoexec Macro 

One day I suddenly reahzed that it was 
a waste of disk space to keep cloning 
ZMATE every time I wanted a tool to 
perform a function with a particular 
macro, and I conceived an approach that, 
in a sense, allows the autoexec macro to 
be specified on the command line. This 
turned out to be enormously usefiil. 

Before I describe how this macro works, 
I would like to show you an example of 
how it is used. First, this will give you 
some idea of what the macro has to 
accomplish. Second, it may give you the 
motivation to slog your way through the 
listing for that macro! 

I often want to make modifications to 
my ALIAS.CMD file. Frequently, I even 
know the name of the alias that I want to 
change. To expedite this operation, I 
wrote an ARUNZ alias that can be in- 
voked with a word as an argument. It 
brings the ALIAS.CMD file into ZMATE 
with the cursor on the first occurrence of 
the specified word. If that's not the right 
occurrence, invoking my "ALT- 
comma' ' instant command will quickly 
search for the next occurrence. Here is 
the listing for the ALED (ALias EDit) 
alias. 



ALED 
aO:; 
bO:edit $$xialias.emd$$b8eies$I$$ 

b9ei.oalias.cmd$Sbtea.8; 
if in U%>pdate pennanently? ; 
mcopy bl5:=alias.cmd /e; 

fi; 

$hb; 



The first line changes to the AO: direc- 
tory, This is where I keep the 
ALIAS.CMD file. It is the root of my 
path and is on a RAM disk. The next 
command (line 2 with overflow to 3) 
invokes ZMATE (which I rename to 
EDIT). More on this command in a 
moment. After the editing has been 
completed, the command on line 4 asks 
if I want to update the permanent copy 



of ALIAS.CMD on the hard disk. If I 
answer affirmatively, then the command 
on line 5 copies the file to B15:, over- 
writing the original file. Line 6 termi- 
nates the flow control state initiated in 
line 4, and line 7 takes me back to the 
directory from which I started all this. I 
have a similar alias, by the way, called 
ZFED (ZFiler EDit) that works on the 
ZFILER. CMD file containing the macro 
key definitions for ZFILER. 

Now let's look at that long editing com- 
mand. Once we allow for the fact that a 
dollar sign must be represented in any 
alias by a pair of dollar signs, we figure 
out that the real command tail is 

$xialias.cmdSb8eies<paraml>$b9ei.oalias.cmd$btea.8 

Here "<paraml>" is the first parameter 
token on the command line by which the 
alias was invoked, namely the word I 
want to search for. 

The autoexec macro treats everything 
before the first dollar sign as the speci- 
fication for the names of the file(s) to 
open for editing and everything after it 
as a macro command to execute after it 
is open. In this case, there is no file 
name; the whole command tail is a 
macro. Since ESC characters cannot be 
entered on a command line, dollar signs 
are used instead. This macro thus be- 
comes the following, to which I have 
added comments and line numbers (and 
where, as in all ZMATE macro listings, 
a dollar sign is used to represent the ESC 
character). 

1 xialia.s.cmd$ ; read in ALIAS.CMD file 

2 b8e ; switch to buffer 8 

3 ies<paraml>$ ; insert text "es<paraml>" 

4 b9e ; switch to buffer 9 

5 i.oalias.cmdS ; insert text ".oalias.cmd" 

6 bte ; switch to buffer T 

7 a ; go to beginningofALIAS.CMD 

8 .8 ; execute command in buffer 



What's happening here is that the 
ALIAS.CMD file is being read into the 
T buffer (note that it is not being opened 
for editing, only read in). Then buffers 
8 and 9 are being filled with text to be 
used as macro commands. The text in 
buffer 8 is a command to try searching 
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for the next occurrence of the word named 
on the ALED command hne, if any. 

The text in buffer 9 is meant to be used 
after any changes have been made to the 
alias definitions. It invokes my perma- 
nent macro "O", which is a version of 
the ZMATE XO (file Output) command 
that prompts for the deletion of any ex- 
isting file of the given name. This al- 
lows me to write out the new 
ALIAS.CMD file right over (on top of) 
the old one. If we have optimized the 
speed of ARUNZ by keeping the 
ALIAS.CMD file early in the directory 
and early on the disk, this would gener- 
ally keep it there. 

The most important thing that I want 
you to take away from the discussion so 
far is that I could have created a special 
COM file, say ALED.COM, to perform 
these tasks. However, this would have 
used up an additional 25K or so of disk 
space, just for this one task. Because of 
the autoexec macro, I was able to accom- 
plish the same function using my stan- 
dard version of ZMATE (EDIT.COM) 
and a short alias definition in 
ALIAS.CMD. In addition, because the 
ZMATE macro specification is in 
ALIAS.CMD and not embedded in the 
permanent macro area of a special ver- 
sion of ZMATE, changes are much easier 
to make. 

Details of the Autoexec Macro 

A commented, line-numbered version of 
the autoexec macro is shown in Listing 
2. Probably some of you will not be 
interested in the details of this macro, 
and you might want to stop reading now. 
However, anyone who uses ZMATE 
macros will pick up a number of inter- 
esting MATE programming tidbits by 
following along. 

My autoexec macro uses buffer 0, which 
is generally considered a scratch buffer, 
and buffer 5. I chose a middle buffer so 
that command-line macros generated by 
the autoexec macro could use both high- 
numbered and low-numbered buffers. 

In line 2, we move to buffer 5 and (line 
3) insert whatever text was in the com- 
mand line tail. ZMATE uses a number 



of special text-source expressions that 
begin with a control-A, here represented 
by caret-A. The control-A can be fol- 
lowed by the number of one of the num- 
bered buffers or by a colon, as here. We 
will see some more examples of this 
later. 

Line 4 begins the processing of the com- 
mand tail. We start at the beginning and 
place the tag there. Then we strip away 
any leading white space. Spaces actu- 
ally would do no harm, but tabs do cause 
a problem. We do this by moving the 
cursor until we encounter the first char- 
acter that has an ASCII value higher 
than that of a space character. Then, in 
line 12, we delete from the tag to the 
present location. 

We now make sure that something is left 
(line 13), If not, we just return now to 
the T buffer and quit (line 15). If there 
is something left to process, we proceed 
to the first major step: spitting the text 
into the part representing the file names 
and the part representing a macro com- 
mand to perform. The boundary be- 
tween these two parts is the first dollar 
sign, if any. 

In line 17 we look to see if the string 
starts with a dollar sign, indicating that 
no file names are specified. If so, we 
delete the leading dollar sign and store 
a ('false' value) onto the numerical 
stack for testing later. If the first char- 
acter is not a dollar sign, then we store 
a 1 ('true' value) onto the stack and 
search for the first dollar sign later in the 
string. Since there might not be one, we 
run the E command (line 22) first, so 
that failure of the search will not halt 
processing. 

Line 24 tests the command error flag to 
see if a dollar sign was found. If not, we 
move the cursor to the end of the text 
(line 25). Otherwise, we delete the dol- 
lar sign (line 27), leaving the cursor on 
the character that followed the dollar 
sign. At this point, the tagged block 
comprises the characters from the begin- 
ning of the siring up to the cursor loca- 
tion. This block contains the name or 
names of files to open. The command in 
line 29 moves this text to buffer 0, leav- 



ing in buffer 5 only the text that repre- 
sents the initial macro command to run. 

Now we begin a block of code that does 
some special format conversions on the 
macro command. There are several 
characters that cannot be entered directly 
on the Z-System or CP/M command line. 
These include lowercase letters (the com- 
mand processor always converts your 
command line to upper case) and control 
characters, including the ESC character. 
The caret character is used as a prefix to 
indicate that the following character is 
to be converted to the equivalent control 
character, while the double quote char- 
acter (") is used as a special escape 
character to indicate that the character 
following it is to be taken as is, without 
special translations. 

This scheme has one minor complica- 
tion. Since we usually type commands 
in lower case and the command proces- 
sor converts them (against our will), the 
autoexec macro normally assumes that 
letters are intended to be lower case, and 
so it converts them back (unless the 
double quote prevents this processing). 
Let's look at how the macro does this 
work. 

At line 32 we begin a repeat block that 
continues until the end of the buffer is 
reached (hne 51). In line 33 we check 
to see if the cursor is on an upper-case 
letter. This test is a little tricky. Because 
ZMATE does not support tests of less- 
than-or-equal-to or greater-than-or- 
equal-to, we have to take a roundabout 
route. We test to see if we are either 
below "A" or above "Z" (i.e., do not 
have a capital letter), but then we negate 
the test with the prime (apostrophe). 
Thus we test for a capital letter. 

If we have a capital letter, we convert it 
to lower case by replacing it by a char- 
acter greater in value by 32 decimal (20 
hex). By representing this in the form 
quote-space (i.e., the ASCII value of the 
space character), the macro does not 
depend on the radix of the number sys- 
tem currently in use. The replacement 
operation moves the cursor to the next 
character, so we go back to the begin- 
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ning of the repeat loop (line 35) to pro- 
cess the next character. 

At Une 37 we check for the quote char- 
acter ("). If found, we delete it, skip 
over the character that follows it (so that 
it is left as is), and loop back to continue 
scanning. This part of the macro code 
allows us to leave a character in upper- 
case by putting a quote character before 
it. We can also enter the three special 
characters ~ quote, caret, and dollar sign 
~ by preceding them with a quote char- 
acter. 

Line 42 of the macro tests for the caret 
character. If it is found, it is deleted 
(line 43) and the next character is forced 
into the ASCII control-code range by 
replacing it with the value obtained by 
logically ANDing it with 3 1 decimal ( IF 
hex, 0001 1 111 binary). 

At line 46 we come to the test for the last 
of the three special characters, the dollar 
sign. If we find one, we replace it with 
the ESC character and loop back. If we 
do not detect any special character, we 
reach line 50 and simply move on to the 
next character. When we reach the end 
of a buffer, the character under the cur- 
sor is the null character with the value 
zero. Line 51 tests for that condition 
and continues the repeat loop if it is not 
true. 

Once we have processed the entire com- 
mand tail text, we can operate using it. 
We go back to the text buffer (line 52). 
Then we pop that value we pushed on 
the stack earlier to remind us whether or 
not we found a file specification earlier. 
If so, we invoke the XF (open File) com- 
mand using as the file name(s) the string 
contained in buffer 0. ZMATE's ability 
to get macro command input indirectly 
from its buffers is one of its most pow- 
erfiil features! 

After we have opened any files specified, 
we clear out the text in buffer (we 
don't want to be sloppy and leave old 
text lying around!) and then execute (line 
57) the macro we composed in buffer 5. 
After that is complete, we again clean up 



after ourselves by clearing buffer 5. 
That's it! 

Plans for Next Time 

I still have a lot more to cover on the 
subject we started this time, and 1 expect 
to have two more installments. How- 
ever, the next issue of TCJ is number 60, 
TCJ's tenth anniversary. Bill Kibler 
asked me to do a reprise on NZCOM and 
Z3PLUS from a beginner' s point of view. 
This won't be easy for me, since I have 
not been a beginner at this for almost a 
decade now! But I'm going to try. I 
plan to take one or two of my spare 
computers and start from scratch bring- 
ing up NZCOM and/or Z3PLUS. In the 
process I will probably discover a num- 
ber of things that don't go quite as easily 
as they should, and some changes to the 
RELEASE.NOT file will undoubtedly 
result. 

In the next installment on ZMATE, in 
issue 61,1 will show a much more elabo- 
rate suite of automatic macros initiated 
from an ARUNZ alias. This is my GEnie 
mail-replying environment. A MEX 
script logs me onto GEnie and captures 
all my new mail into a file. The ZMATE 
macros then automate the process of 
creating reply messages for later upload 
to GEnie, 

A third installment I have in mind will 
show how ZMATE-based text process- 
ing can be used to automate other com- 
puting tasks. Recently I have been using 
ZMATE (actually PMATE) extensively 
this way on my DOS computer. For 
example, I have been running numerous 
circuit simuladons in which I want to 
vary some parameters. For each simula- 
tion I used it invoked PMATE, found the 
lines in the circuit definition file that 
needed to be changed, entered the new 
values, saved the file, and invoked the 
simulator. Now 1 just write an alias 
(batch file) that does the whole thing 
automatically. It generates a PMATE 
command with a macro in the command 
tail to insert the new parameters. In 
some cases, I even have another com- 
mand in the batch file that instructs 
PMATE to examine the simulator's out- 
put file and determine whether the cir- 
cuit performed properly. The batch file 



can then automatically adjust the circuit 
parameters and start the cycle again. 
The most dramafic example of this was 
when I went away on vacation for almost 
a month. The computer worked the 
whole time unattended, and when I got 
back, I had a nice text file with all the 
results neatly summarized. 



To contact Jay use, JAY. SAGE on 
GEnie, or sage@ll.mit.edu on internet. 
Alternately try one of his phones or BBS 
numbers listed in the SAGE 
Microsystems East advertisement on the 
inside cover of this issue. 



Listing 1. 

, Macro to convert text in an entire file to upper case 
; and then write out file and exit There is code to 
; force disk scrolling. 



»s 


autoexec macro 


b1e 


go to buffer 1 


i*A:$ 


insert command tail 


bte 


return to buffer T 


xfA^n 


open files named in buffer 1 


[ 


REPEAT 


(@t<"a)!(@t>'z){ 


IF char outside range a.z 


; (i.e., not lower case letter) 


m 


just move to next character 


}{ 


ELSE 


@t-" r 


replace with upper case char 



(by subtracting 32) 



@t=OU 



continue 



xe$ 
xh 



ENDIF 

IF end of buffer of file 
try moving to next character 
IF still end, exit repeat loop 
otherwise, move back and 

; ENDIF 

; END REPEAT 

; end editing 
; exit MATE 



Listing 2. The full definition of my autoexec macro with 
comments and line numbers. 



01 *s 


lAutoexec Macro 


02 BSE 


work in buffer 5 


03 l"A:$ ; insert command line argument string 


04 A 


start at beginning 


05 T 


tag it 


; Skip over white space 




06 [ 


REPEAT 


07 @T>"{ 


IF char higher than space char 


08 


exit repeat loop 


09 } 


ENDIF 


10 U 


move to next character 


11 1 


END REPEAT 


12 #D 


delete the block of white space 


13 (@T=0{ 


IF nottiing left 


14 BTE 


go immediately to T buffer 


15 % 


exit this macro 


16) 


ENDIF 


17 @T="${ 


IF first character is dollar sign 


18 D 


delete it 


19 0, 


push (false) onto stack 


20 }{ 


ELSE (first char not dollar sign) 
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21 


-1, 






push 1 (true) onto stack 








48 « 




start next loop 


22 


E 






turn off error trapping 


36 


@r--{ 


IF character is double quote 


49 ) 




ENDIF 


23 


S$$ 






search for first $. if any 


37 





delete it 








24 


&B{ 






IF none found 


38 


M 


move past following character 


50 M 




move to next character 


25 


Z 






go to end of text 


39 


A 


start next loop 








26 


K 






ELSE (dollar sign was found) 


40 


} 


ENDIF 


51 l@T=0] 




UNTIL we reach end of buffer 


27 


-D 






delete the dollar sign 














28 


> 






ENDIF 


41 


@T="«{ 


IF character is caret 


52 BTE 




go to buffer T 


29 


#BM 






move preceding text to buffer 


42 


D 


delete it 


53 @S{ 




IF stack contents true 


30 


) 


; Reformat the macro passed on command tine 


43 


@T&31R 


replace char with control char 


54 XF«A@0$ 


open file spec in buffer 












44 


« 


start next loop 


55) 




ENDIF 


31 


( 






REPEAT 


45 


) 


ENDIF 


56 BOK 




clear out buffer 


32 


«!<■ 


A!(eT> 


■Z)'{ 


IF upper case character 


46 


@T="${ 


IF character is dollar sign 


57 5 


; execute macro passed on cmd line 


33 


BTt 


"R 




replace it with lower case char 


47 


■■$R 


replace with ESC character 


58 B5K 




clear out buffer 5 


34 


A 






start next loop 












end of macro 


35 


} 






ENDIF 
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32-Bit Systems 

All Readers 

MINIX File System 



Real Computing 

By Rick Rodman 



Each crisis we face seems much less 
daimting when it has passed. But there, 
in the thick of it all, is the true test of our 
Insight, our Ingenuity, and our down- 
right Determination, in the true TCJ 
Ethic, to Do The Job with the Tools At 
Hand. No words can truly convey the 
Challenge, the Struggle, and the Exhila- 
ration of Triumph. 

The Superblock is Corrupt! 

It was a day like any other, when these 
chilling words that strike fear into the 
heart of any Minixer appeared from my 
PC-532, "The Superblock is Corrupt!". 
The initial despair gave way to a resolute 
determination to fix the problem. This 
problem can occur on any Minix system. 
Minix-PC and the PC-532 use identical 
file systems, and the Atari ST and Amiga 
use the same file system but with b>les 
' reversed. 

The tools required are: First, some means 
of reading and writing sectors in the 
Minix partition or volume outside of 
Minix. Second, a bootable Minix dis- 
kette, or set of diskettes, with/vcA- some- 
where available, with /dev/hd2 acces- 
sible but not the system disk. 

In the Minix-PC emdronment, these tools 
take the following form. For the first 
requirement, you need a DOS partition 
or a bootable DOS diskette and a read- 
write tool similar to READABS. The 
second tool is your Minix-PC diskette 
set. 

In the PC532 environment, the reading 
and writing can be done with the moni- 
tor. The other tool needs to be made - 
you need one disk with a bootable image 



(the hard disk is fine), and another disk 
with a complete file system arvifsck. 

One would think that fsck alone could 
fix a corrupt file system. That's what 
it's supposed to do, after all. Unfortu- 
nately, fsck can't fix the file system - it 
won't even try - if the superblock has 
been damaged. 

Before we get to work fixing the blown 
superblock, here's a brief explanation of 
the Minix file system. By these words 
"file system" I mean the overall struc- 
ture placed on a floppy diskette or hard 
disk partition, within which files are 
created by the operating system. 

A Minix file system consists of a IK 
(1024-byte) "boot block", the 
"superblock"; some number of 
"inodes"; and the data in "zones". 

The "boot block", on a floppy, could 
hold the BPB (Boot Parameter Block 
explained in my "Mysteries of PC Floppy 
Disks Revealed" article on page 16 of 
issue #44) or possibly a short boot pro- 
gram. On the hard disk, however, the 
partition table is in the first sector, so 
there's no need for anvlhing to be in the 
boot block. Because PC hardware al- 
most always uses 512 b>le sectors (due 



to a logic bug in DOS I.O), two sectors 
are required for each IK Minix block. 

The "superblock" comes next. It's an 
1 8-byte data structure at the second Minix 
block of the file system. It consists of the 
values listed in figure I . 

The definition for this structure is in fs/ 
super, h on page 540 of the Minix 1.5 
source listing. A whole block, IK b>tes 
or two sectors, is allocated to the 
superblock. 

There is some number of "inodes," 
which correspond to directory entries, or 
the FAT under PC-DOS, but are a little 
different. Each inode is a 32-byte data 
structure very similar to a CP/M direc- 
tory entry, but with no name in it. As in 
CP/M, there must be a number of inodes 
such that they take up an even number of 
IK blocks. 

The inode has date and time in it, at- 
tributes, and a short list of block num- 
bers. These block numbers point to the 
first few blocks of a file. Once the file 
goes beyond that many block numbers, 
though, instead of allocating another 
directory entr>' like CP/M does, a data 
zone is allocated, and more block num- 
bers written there. That block is called 



1 . 2 bytes - number of inodes on the file system 

2. 2 bjles - number of zones on the file system 

3. 2 b>1es - inode bit map size in IK (1024-byte) blocks 

4. 2 bytes - zone bit map size in IK blocks 

5. 2 bytes - first data zone 

6. 2 bytes - log 2 of blocks per zone - always 00 00 (see below) 

7. 4 b>tes - max. size - always 00 IC 08 10 hex (This is 262,663 decimal 
see text) 

8. 2 bytes - magic number (7F 13 hex) 

Figure 1 Superblock Structure 
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a "single indirect block". If that block 
fills up, then another data block is allo- 
cated, and the block numbers of the in- 
direct blocks are written there - this is a 
"double indirect block". If the block 
numbers are two bytes each and the in- 
direct blocks are IK bytes, you can have 
seven direct blocks, one single-indirect 
block from the inode, one double-indi- 
rect block, and 512 single-indirect blocks 
from the double-indirect block, for a 
maximum file size of 7 + 512 + (512 * 
512) blocks, which works out to be 
262,663 blocks or 268,996,912 bytes. 
Since a Minix partition can't exceed 64 
megabytes, that's plenty big. (In Unix, 
you can have triple-indirect blocks.) The 
definition of the inode structure is in fs/ 
inode.h on page 535 of the listing. 

But wait, you say, how do I find a file if 
there's no filename? The filename isn't 
in the inode because it's in a director^' 
somewhere. A directory is a regular file 
with a special attribute, with all of its 
space out in the data area. Each entry in 
a directory has a two-byte "inode in- 
dex", from to the number of inodcs 
minus one, plus a 14-character filename. 
Using the inode index, it's quite easy to 
go to the inode and thus to the file data. 
But, if you ever need to go from the 
inode to the file name, out in some direc- 
tory, that's quite a difficult thing to do. 

Also note that there's nothing prevent- 
ing two directory entries from pointing 
to the same inode. This could happen 
quite easily by accident, or we might do 
it deliberately. In Unix parlance, this is 
called a "hard link", because Unix has 
another kind of link called a "symbolic 
link", which goes through the filename. 
There's a link count field in the inode, 
inlinks, which keeps track of how many 
files point to the same inode, so that if 
you should erase one of the linked files, 
the other one doesn't get lost. 

After the inodes comes the actual user 
data, in "zones". The "zone" is like 
an MS-DOS "cluster" or "allocation 
unit' ' - it is the granularity in which data 
space is allocated by the operating sys- 
tem. Actually, for all intents and pur- 



poses, a zone is the same as a block - IK 
bytes. 

You might pause for a moment and make 
sure you understand all of the foregoing 
before proceeding. To read more about 
this, the place to go is Andy Tanenbaum's 
book. The Minix manuals don't waste 
any time describing these details. This 
complex inode and indirect-block struc- 
ture, with the filenames separated, is 
traditional in Unix and Unix-like sys- 
tems - and that tradition, not its effi- 
ciency or speed, is the reason it is used. 
In actuality, compared to most other 
designs, it is inefficient and slow, and, 
in my opinion, the "hnk" feature is 
really just calling a bug a feature. 

There are some "Unix believers" who 
will sincerely argue that this is the most 
efficient system possible. These people 
are wrong, of course, but they will de- 
fend to the death the Standard Unix way 
of doing things no matter how bad it is, 
just Because It Is Unix. When really 
pressed, they'll try to dismiss a topic as 
a "Religious Issue", which is a face- 
saving way of saying "I see I'm wrong, 
but I'll never admit it". 

Now that we've got a basic understand- 
ing of the Minix file system, let's get 
started fixing the blown superblock. 
Obviously, a lot of trouble could be saved 
if you already have a hex dump of what 
your superblock is supposed to contain. 
If you're a Minix user, I urge you to go 
and dump the second IK block of each 
of your Minix partitions. Print them out 
and save them - because only you can 
rescue your superblock. 

But now, we're going to rebuild the 
superblock by recomputing all of the 
values in it. We have to start with the 
number of zones of the file system. Now, 
in theory, you could have multiple blocks 
per zone; in practice, nobody would, 
because Minix can't handle more than 
64K blocks anyway. So, #2 of the 
superblock is just the number of kbytes 
of the partition, low-byte-first. 

The zone bit map is an array of bits, one 
per zone, saying whether each zone has 
been used or not. We need one bit per 
zone for the zone bit map. How many 



blocks is that? Well, it's #2, divided by 
eight, plus 1023, divided by 1024. Con- 
vert the result to hex, low-byte-first, and 
that's #4. Did I mention you need a hex 
calculator? 

The number of inodes in a given file 
system could be anjlhing. This is the 
problem. 1 had to go looking through 
the disk with the monitor to see where 
they ended, but there appears to be a 
general rule; the number of zones di- 
vided by 3. Oddly, mkfs doesn't always 
bother padding this value to some mul- 
tiple of 32, so some space is wasted. I 
think it should be rounded up: Take #2, 
divide it by 3, and round up to next 
multiple of 32. Express as hex, low- 
b>le-first, and that's superblock item #1. 
It wouldn't have to be this value, and it 
might not - but in my case, it was. 

Like the zone bit map, there's an inode 
bit map. If you have 8,192 inodes or 
less, you need one block; otherwise, you 
need 2. Put 01 00 or 02 00 as #3. 

The only thing left is the starting data 
zone. This is I (boot block) plus 1 
(superblock) plus #1 fimes 32 divided by 
1024, plus the two bit map sizes. Calcu- 
late hex and store low-byte-first as #5. 

Fill in #7 and #8 with the fixed values 
indicated, and you've got your superblock. 
Use the monitor or absolute writer to put 
this block at the beginning of 
superblock 's block, and you should be 
able iofsck the partition. In my case, the 
partition was 17336 blocks (hex B8 43), 
had 5792 inodes (hex AO 16), and the 
starting data zone came to BB hex. 

Once you write out the corrected 
superblock, you're almost there. Boot 
on the bootable floppy, then run fsck / 
de\'/hd2 - because hdO is the whole drive, 
and hdl is the little boot partition - and 
you should end up with a clean file sys- 
tem. I did! 

Another Tale of Woe 

For some folks, a bridge is something 
you walk or drive over, and a router is a 
tool used to make scroll work in wood. 
But we in the computer world have our 
own crazy vocabulary. I think I'm the 
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only person in my neighborhood with a 
LAN in the basement. In fact, it's sort 
of two LANs, one thinnet Ethernet and 
one Token Ring. 

At any rate, I strove to bring my OS/2 
2.0 system up on the Netware LAN un- 
der Token Ring. It was refiised admis- 
sion! This situation persisted for days. 
Yet the machine was accessible via 
NetBIOS, so it couldn't be a hardware 
conflict ... right? Of course the only 
error was "Unable to get connection 
ID", one of those "Something is wrong" 
type of messages. (On another topic, the 
only error message in MSCDEX is "In- 
correct DOS version' ' - which it says no 
matter what is wrong.) 

Finally, however, I decided to dust off 
the little test utility that comes with the 
Token Ring boards. Nobody but a para- 
noid person like me even keeps these 
diskettes, because they do almost noth- 
ing. Well, this utility came up with the 



interesting fact that, while the board 
worked fine, it had to move the RAM 
buffer to CCOOO, because there was a 
conflict at DCOOO where most software, 
including the LAN Support Program, 
expected it to be! 

The manual on this board makes no 
mention of the RAM buffer address need- 
ing to be at DCOOO or anywhere else. In 
fact, it never mentions the I/O address 
either, which is 220-227 hex and A20- 
A27 hex. So, I had a conflict with the 
SCSI board, which I had moved because 
of a conflict with the graphics board, 
which I had moved because of a conflict 
with the Token Ring board... Just ex- 
actly where are these "holes in the 
memory map" I keep hearing about? 

Back in the Z-80 and CP/M days, we'd 
have "banked out" all of these video 



and network boards, and they'd only be 
"switched in" when they were actually 
being accessed. There 'd never be any 
conflict. Keep reminding me how we've 
made progress since then. 

Well, to make a long story short (which 
Ed. will appreciate), the graphics board 
is out and all the conflicts are resolved, 
and the OS/2 2.0 machine is now a proud 
constituent of the LAN. 

Next time 

Next time we go Back to Basics to ex- 
plore the fundamentals of Minix, Coher- 
ent, and other Unix look-alikes. Plus, 
we discover the Mother Load - the source 
of much code in seedy Rome. In the 
meantime, may you never long for an int 
that's not short. 

Where to call or write 

BBS or Fax: 1-703-330-9049 



Sending Articles to TCJ 



Send your articles and letters of inquiry to: 



The Computer Journal 
P.O. Box 535 
Lincoln, CA 95648 



The editorial policy is to seek articles that can enhance and educate our readers. Letters of interest will be printed in our Reader 
To Reader section on a space and topic consideration. Material is typically printed "as is", however TCJ does reserve the right 
to reject or modify (by omitting) portions of letters or articles deemed unfit for pubhcation. Any letters received by TCJ or 
it's technical editors may be printed or included within an article unless YOU indicate otherwise. Your name and city/state 
only will be used unless YOU indicate that you desire to have your full name and address included in references or letters 
printed. 

Major letters and minor articles are accepted on floppy disk or by network services and will aid in getting your letter published 
"as is." TCJ does NOT return disks and material unless suitable and appropriate return mailers and postage is provided. 

Floppy disk and word processing formats support by TCJ, are 3.5, 5.25, and 8 inch disk formats. Several CP/M to PCDOS 
conversion programs are used to transfer data for editing under WordStar with final output under PageMaker 4. Please do 
not use embedded punctuations in file names which can prevent reading by transfer programs. WordStar 7 can read and 
convert most other word processing programs output, but providing at least one ASCII file is recommended. Use of GENIE 
(as B.Kibler) and CompuServe (ID: 71563,2243) is the preferred method of sending information and articles to TCJ. Please 
ZIP files with a README, your .article and an ASCII text version included. 

TCJ is currently looking for articles that show our readers how you are still using older systems. Those systems can be anything 
except PC clone machines (machines like MBC 550 which are NOT 100% compatible are OK!). Your article should be written 
as ifyou are talking among friends and recounting your experiences. Please make it clear that "YOU" did this, and "I" had 
these problems, which "I" was able to resolve using these steps and techniques. The readers level of knowledge ranges from 
beginner to advanced. All references should provide a brief review of information to assist readers in determining the 
importance of the reference in relation to their own needs. 
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TURNKEY APPLICATIONS DEVELOPMENT 

IN FORTH 

by Frank Sergeant 



Special Feature 

Intermediate Users 

Forth Operations 



How do you develop a turnkey application in Forth? That is, 
after you have developed your application, how do you make 
it run as a stand-alone program? After all, forth is strange. If 
you are used to other languages you may keep looking for the 
compiler and linker and never find them. How do you wrap up 
the application so you can ship it to a client or use it yourself 
from the DOS command line? 

Let's divide the universe of possible applications into those that 
run on general computers and those that run on dedicated 
computers (' 'embedded' ' systems). The two need to be handled 
somewhat differently. This article concentrates on the first 
class. 

General Computers 

Suppose you write a calculus tutor in Forth that you hope to 
distribute on a disk. You'd like the customer to be able to do 
a directory listing of the disk, see your executable file, type in 
its name at the operating system prompt, and have the calculus 
tutor come up, but _not_ have the Forth system come up. 
Right? I'll describe how to do this in Pygmy Forth. 

You must do five things: 

1. Write the application and test it. 

2. Create a special startup word that initializes and runs the 
application. 

3. Create a special error handling word that prints error mes- 
sages and restarts the application. 

4. Install the new boot and abort words. 

5. SAVE the COM file. 

Step 1. Write the application. 

HopefiiUy you write the application incrementally, testing each 
piece exhaustively from the keyboard, thus making a very 
sturdy system. It culminates in a single high-level word, 
perhaps TUTOR. All this tested code resides in block files (ok, 
you could use text files instead if you insist). So, load the 
application by typing 4001 LOAD or " TUTOR.TXT" 
FLO AD or whatever. See the listing at the end of this article. 



Blocks 4002, 4003, and 4004 show an extremely simple calcu- 
lus tutor program. 

Step 2. Define the startup word. 

Next write your own startup word which handles any special 
initializadon, such as opening files, loading in a table from 
disk, or setting screen colors. It must finally execute the main 
word of your application. Suppose you name your startup word 
TUTOR-BOOT (defined on block 4005). We want to arrange 
things so that Pygmy will execute TUTOR-BOOT when it 
starts up, rather than displaying a greeUng and waiting for you 
to type Forth commands. The word BOOT is to Pygmy more 
or less what AUTOEXEC.BAT is to MS-DOS. BOOT is a 
DEFER' d word which points to another word which is actually 
executed whenever Pygmy begins. We won't do it yet, but later 
we make BOOT point to TUTOR-BOOT by typing 

' TUTOR-BOOT IS BOOT 

This will ' 'vector' ' BOOT to TUTOR-BOOT, which initializes 
things and then executes TUTOR. The default in Pygmy is for 
BOOT to execute the word (BOOT. Use (BOOT as a model, 
if you like, when designing your own startup word. 

Step 3. Define the custom error handler. 

What happens, though, if an error occurs? The word ABORT 
will print an error message, clean up the stacks, and execute the 
Forth main loop QUIT. This is perfect during development but 
it is not what you want the final application to do. You 
probably want to print an error message and then either restart 
the application or exit gracefully. Fortunately, ABORT is also 
a DEFER'd word. It normally executes the word (ABORT, but 
you can write your own routine instead, as described above for 
BOOT. Let's call the custom error handler TUTOR-ABORT 
(defined on block 4005). T>ping 

' TUTOR-ABORT IS ABORT 

would install the new error handler in place of the default 
(ABORT, but don't do it yet. 

In order to exercise our error handler, we need an error. So, 
in block 4004, the definition of TUTOR contains a test for the 
' 'error condition' ' of the user pressing the Enter key instead of 
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a digit. If only this were the most serious error we needed to 
guard against. 

Step 4. Install boot and abort words. 

OK, you can do it now. That is to say, during the development 
process you will leave BOOT and ABORT alone. Then, when 
you have finished testing, the last thing you do before saving 
the .COM file is re-vector them to your custom words by typing 

' TUTOR-BOOT IS BOOT 
' TUTOR-ABORT IS ABORT 

as shown on block 4001. 

Step 5. Save the .COM file. 

Finally, as shown on block 4001, save the system by typing 

SAVE TUTOR COM 

Type BYE to get back to DOS and run your new turnkey 
application by typing TUTOR at the DOS prompt. The saved 
file (i.e. TUT0R.COM) is your turnkey application. When you 
or your customers run it the underlying Forth is never seen 
because BOOT executes TUTOR-BOOT. Then TUTOR-BOOT 
executes TUTOR. As TUTOR-BOOT's final step it execute 
BYE to return the user to DOS. 

Snapshots 

As you are developing in Pygmy, but before you are ready to 
produce the shippable application, you can take a "snapshot" 
of your system at any time with the word SAVE. When doing 
this, there is no need to re-vector BOOT or ABORT. Just type 

SAVE TST1.COM 

Then, when you later execute TSTI.COM from DOS, the 
extensions to the dictionary will be there without needing to be 
reloaded. The files open at the time of doing the SAVE will 
be opened automatically. 

Getting Fancier 

The approach described above for making a turnkey version of 
your application is very easy to do and works great. The .COM 
file is guaranteed to be less than 64K bytes long. In this day 
of bloated applications, that's not considered very large. Of 
course, depending on the size of your apphcation, the file 
might be much smaller than 64K. However, there are some 
addidonal steps you can take to make the COM file smaller. 
You can make many of the words headerless. You do this a 
word at a time by preceding each word with | (a vertical bar). 



or a whole group of words at a time by surrounding the group 
with HEADERS-OFF and HEADERS-ON. 

Another trick is to use just the kernel of Pygmy (around 8K). 
Don't load the editor. Don't even load the assembler unless 
your application defines new CODE words. Do this as the last 
step, because you want the editor present during development 
but not in the final application. 

If you need the assembler, but do not want it taking up space 
in the final application, you can load it "high" by using curly 
braces around it, ie { 1 12 132 THRU } then load your CODE 
words (they need the assembler), then unlink the assembler 
with the word PRUNE. For example, you might start with the 
Pygmy kernel (about 8K bytes) and use the following load 
block, assuming your application uses several code words on 
blocks 6002 through 6008: 

{ 112 132 THRU } ( temporarily load the assembler) 

HEADERS-OFF ( optional) 

6002 6008 THRU ( define the CODE words) 

6010 6020 THRU ( load rest of application) 

' NEW-BOOT IS BOOT ( startup word) 

' NEW-ABORT IS ABORT ( error handler) 

HEADERS-ON (optional) 

PRUNE ( throw away the assembler and headers) 

SAVE NEWAPP.COM ( make turnkey .COM file) 

Note, we vectored BOOT and ABORT _before_ we threw away 
their headers! 

Dedicated Systems 

This section will be a little sketchier. I'll just touch on a few 
possibilities. I expect to have a lot more to say about dedicated 
systems in a ftiture article. 

Suppose you are building a stand-alone microprocessor gizmo 
(the target system). The final code will probably need to be 
burned into an EPROM. Let's assume the host is a PC. If you 
object to this, please consider my arguments in the last section 
of this article. During development the PC is connected to the 
target system by a serial line. Here are some possibilities: 

1. The target system is a PC (80x86 processor) 

2. The target system uses any small microprocessor 

a. with Forth 

b. with a monitor ROM 

c. with nothing (just RAM you download to, or an EPROM you 
program) 

This simplest situation is if the target system is also a PC, and 
you are willing to run under DOS, possibly booting from a 
floppy. Just develop the system as described in the first part of 
this article and set up an AUTOEXEC.BAT file that loads your 
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turnkey application .COM file. In this case, naturally, you do 
not need the serial line or the second computer. 

However, if the target system is a PC but you do _not_ want to 
run under DOS, things get a little more complicated. Perhaps 
you'd like to stick the PC in a cabinet, perhaps without a 
keyboard, monitor, or even disk drives, to let it control some 
machinery. You'll have to avoid using any DOS calls (since 
DOS will not be present). You'll have to write some initial- 
ization code so the POST (power on self test) of the BIOS ROM 
will recognize your ROM and turn control over to it. Even 
though you plan to burn the code into a ROM, you must decide 
whether to actually _run_ it out of ROM or out of RAM. I 
suggest running it out of RAM for simplicity. If you choose 
RAM, the initialization routine must copy the code from the 
ROM to RAM, then jump to the RAM to execute it. If you 
choose ROM, you must alter how Pygmy handles VARIABLES 
so they get directed to RAM instead of to memory which cannot 
_actually_ vary. See the source code for Pygmy's system 
variables for a hint on how to do this. 

If the target system is not a PC, but perhaps some simpler micro 
miming a Forth, you can use Forth on the PC as a smart 
terminal to talk to the target system's Forth and supply the 
editor and disk services (and keyboard and video display, of 
course). 

If the target system does not have Forth, but does have a 
monitor ROM, you can still control it from Forth on the PC. 
You can either use Forth as a terminal program allowing you 
to type monitor commands, or you can define various macros 
to talk to the monitor for you, thus automating some of your 
typing. 

The last choice, a target s>'stem without even a monitor ROM, 
presents an interesting problem. The Motorola 68HC11 
microcontroller is excellent for this because it has a special 
bootstrap mode. In that mode, it starts up in a loop waiting for 
you to download a program to its RAM. So, although _you_ 
may not have put a ROM on the target system, the micropro- 
cessor itself has a tiny boot loader ROM built-in. There is 
already an 'HCII assembler that runs on Pygmy on a PC that 
generates code for the 'HCll (it's on the Pygmy Bonus Disk). 
So, assembly language development is easy enough with this 
combination. Also, I described a simple monitor program for 
the 'HCl 1 in the 1991 FORML Conference Proceedings (avail- 
able from the Forth Interest Group). For other microproces- 
sors, the trick will be to get _something_ running so you can 
get some feedback so you can start to figure out what's going 
on. More on this later. 



Frank uses Forth for everything from writing business software 
to controlling hardware. He can be reached at F. SERGEANT 
on GEnie or fs07675@swtexas.bitnet, or c/o Famous Math- 



Why a PC Makes A Good Host 

PCs are cheap but sturdy. You can buy surplus original 
IBM PCs for less than dumb terminals for CP/M ma- 
chines used to cost (just to try to put things in perspec- 
tive). PCs are plentifiil. Just like the industrial revolu- 
tion, they use interchangeable parts, and there is lots of 
competition by makers of those parts, which keeps 
prices down. Monochrome graphic video boards are 
easily available for under $20, for example. I don't say 
PCs make the only possible host (I certainly would 
jiot say that in this magazine!). I think I've seen 
surplus original PCs available for under $150, with 
monitor; XT motherboards for around $30, It's some- 
thing to keep in mind. Frank Sergeant. 

This is getting to be a hard topic to talk about these 
days. Yes, the cost of PC Clones is dropping and there 
can be little price difference between an OLD CP/M 
system (typically $50 with all the software) and PC/XT 
clones. Where I differ is how you use it. Is it a devel- 
opment system using purchased software or your own 
developed utilities. If you only buy software, then PC 
Clone machines are probably good deals (watch out 
however, most new packages will not run on older PC/ 
XT machines). 

If you generate your own support, then CP/M machines 
may be better. The main difference is whether you use 
the machine as an appliance or play with it as well. One 
also needs to check on how complex your application is. 
I find the tools available with Pygmy and FPC currently 
superior to F83 for CP/M or PCDOS. Those superior 
tools will work on most PC/XT machines ( FPC nor- 
mally needs a hard disk, but can be made to work from 
floppy) and make great cross-development platforms. 
Programs wTitten for F83 however can run on either 
platform (CP/M, CP/M68K, or PCDOS) without modi- 
fication or hard disks if properly done. 

The direction at TCJ is to provide code that can be used 
on as many different platforms as possible, and thus 
leave the choice up to you and your pocketbook. We are 
also considering supporting older PC based machines 
(such as Sanyo MBC 550) as these are not true clones 
and currently are not supported by any magazines. 
These non-clone machines all t>'pically have I28K or 
256K of memory and can run only the smallest of 
programs (great for Pygmy programs). Bill Kibler. 

Your comments on this subject are always welcome! 
Please send us your thoughts and ideas for a special 
article on HOST Svstems "TO PC or NOT to PC?" 
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ematicians Academy (hey, it works for artists). Pygmy v 1.4 is 
available from FIG, ftp at asterix.inescn.pt (evenings), etc. 



Block 4000 

Example code for turning a simple application into a 

turnkey .COM file. 

Steps; 

1 . Write the application and test it. 

2. Create a special startup word that initializes and 
runs the application (see TUTOR-BOOT). 

3. Create a special error handling word that prints an 
error message and restarts the application 

(see TUTOR-ABORT). 

4. Install the new boot and abort words. 

5. SAVE the .COM file. 



Block 4001 

( Load block for a simple application, a Calculus Tutor) 

4002 4005 THRU 

' TUTOR-BOOT IS BOOT 
' TUTOR-ABORT IS ABORT 

SAVE TUT0R.COM 



Block 4004 

( Rudimentary Calculus Tutor) 

: TUTOR ( -) 

QUESTION ANSWER (key) 

DUP 13 = ABORT" You entered a carriage return." 

CR ( key) 

RIGHT? ( f) IF REWARD ELSE CONSOLATION THEN 

CR CR 7C0NT1NUE ; 



Block 4005 

( Custom BOOT & ABORT routines) 

: TUTOR-BOOT ( -) 

$1F ATTR ! ( set colors to white on blue for CGA or VGA) 

TUTOR ( ie run application) 

BYE ( ie return to DOS) ; 

: TUTOR-ABORT ( -) 

>SCR ( just in case) 

BEEP CR ." Utoh, utoh, a serious error has occurred: " 

CR POP POP TYPES ( ie print the error message) 

SP! RP! CR ( ie reset the stacks) 

7C0NTINUE 

TUTOR-BOOT ( ie restart the application) ; 



Block 4002 

( Rudimentary Calculus Tutor) 

: QUESTION ( -) ." What is 2 + 2 ? " ; 

: ANSWER ( - key) KEY ; 

: RIGHT? ( key - f) '4 = ; 

; ?CONTINUE ( -) 

CR ." press a key to continue" KEY DROP 



Block 4003 

( Rudimentary Calculus Tutor) 

; REWARD ( -) 

CR . " Congratulations, you have been accepted by the' ' 

CR . " Famous Mathematicians Academy to study for a career' ' 

CR ." in mathematics. Please send $1200.00 cash to" 

CR ." Famous Mathematicians Academy" 

CR ." 809 W. San Antonio Street" 

CR." San Marcos, Texas 78666" 

: CONSOLATION ( -) 

CR ." Ur, uh, not quite, but you are showing potential." 

CR ." Please try again soon." ; 



Names used in the article that are likely to be trademarked: 
Motorola, MS-DOS, IBM, CP/M 



Help TCJ BY RENEWING EARLY 
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renew early, this saves on mailing you a bill 
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The Computer Journal 
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IMSAI MPU-A 



This issue's center fold is the IMSAI MPU-A S-IOO 8080A 
CPU board. The description and schematic are from the origi- 
nal manuals produced in 1975. Except for my one reference to 
see a note, this is the original text supplied with the board. The 
note and changes to the schematic represent solutions to 
problems I personally encountered some years back. If you 
encounter problems bringing one of these units up, pay close 
attention to the note and check your other boards for compat- 
ibility with all S-IOO lines used and unused. Bill Kibler. 



MPU Revision 1 

FUNCTIONAL DESCRIPTION 

The MPU-A board is the processor board for the IMSAI 8080 
Microcomputer System. It is designed using the Intel 8080 
micro-processor chip. The bus arrangement and board connec- 
tor has been chosen to be 100% compatible with the MITS 
Altair M8800 Microcomputer system so that all boards are 
100% interchangeable between the Altair system and the IMSAI 
8080 system. 

Every effort has been made to keep the desiqn simple and 
straight-forward to maximize reliability and ease of mainte- 
nance. MSI and LSI are used where appropriate, and discrete 
components are held to a minimum for greater circuit reliabil- 
ity and ease of assembly. 

The 8224 clock driver chip and an 18 Megahertz crystal are 
used to generate the 2-phase, 2 Megahertz non-overlapping 
clock for the 8080 A. An 82 12 is used as a latch for the status 
signals and two 8216 tri-state bi-directional bus drivers are 
used to interface the 8080A with the IMSAI 8080 input and 
output data buses. All other address, status, and control lines 
are driven by tri-state bus drivers. 

Unregulated +16, -16, +8 volts, and ground must be supplied 
to the bus. On-board regulation is used to arrive at the power, 
supply levels needed to run the chips. Integrated circuit power 
regulators with overload protection are used. The board is 



supplied with ample bypass filtering using both disc ceramic 
and tantalum capacitors. 

The board connector is a 100 pin edge connector on . 125 inch 
centers 50 pins on each side. Dimensions are 5 inches by 10 
inches, using 2 sided glass reinforced epoxy laminate, with 
plated feed through-holes to eliminate the need for any circuit 
jumpers. The contact fingers are gold-plated over nickel for 
reliable contact and long life. All other circuitry is tin-lead 
plated for better appearance and more reliable solder connec- 
tions. 

Power-on reset is included on this board along with pull up 
resistors for all inputs required so that with the front panel 
removed from the IMSAI 8080 machine, the power-on reset 
will start the program at position O out of a ROM. All other 
necessary conditions are met so that the system will run with- 
out the front panel attached (see notes BDK), for use in dedi- 
cated controller apphcations where no operator-processor in- 
teraction is desired. 

THEORY OF OPERATION 

The IMSAI MPU-A board is structured around the Intel 8080 A 
microprocessor chip, and much of the MPU-A board is wired 
to support the 8080A device. The MPU-A board provides 
interfacing between the 8080A chip and the data and address 
busses, clock and synchronization signals, and the voltage 
regulation necessary for the 8080A and other chips. The 
internal functioning of the 80 80 A is thoroughly described in 
the Intel 8080 Microcomputer System User's Manual. Refer- 
ence should be made to this manual for Information concerning 
the operation and use of the 8080 A. 

The address lines from the 8080A drive the address bus on the 
back plane through 8T97 tri-state buffer drivers. These drivers 
may be disabled through the ADDRESS DISABLE hue on pin 
22 of the back plane. Intel 8216 bi-directional bus drivers 
connect the 8080's bi-directional data bus to the back plane's 
dual uni-directional DATA IN and DATA OUT busses. The 
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direction of data transmission is determined by the DIREC- 
TION ENABLE line. The DIRECTION ENABLE line is in 
turn controlled by the front panel and the processor status 
signals DATA BUS IN and HALT ACKNOWLEDGE. The 
82 16 can be disabled by the DATA OUT DISABLE line on pin 
23 of the back plane. 

The 8080A's bi-directional data bus is also connected to the 
data bus socket and the 8212 status byte latch. The data bus 
socket is used to connect the front panel to the bi-directional 
bus, while the 8212 latch transfers the status byte to the back 
plane via 8T97 drivers. These drivers are disabled by the 
STATUS DISABLE line on pin 18 of he backplane. The 8212 
is latched up by the STATUS STROBE signal of the 8224 clock 
chip to store the status information for each instruction cycle. 

One K puUup resistors to +5 volts are connected to all the bi- 
directional bus lines to ensure that during the time the bus is 
not driven, the 8080A reads all I's. 

The 8224 clock chip and crystal oscillator, provide the two- 
phase non-overlapping 2 megacycle system clock for the 8080A. 
These clocks are also driven onto the back plane through 8T97 
tri-state buffered drivers. 

The CLOCK line on the back plane is driven from the TTL 
Phase II clock Une through a delay so that the phase relation 
of the clock signal to the Phase II and Phase I back plane 
signals, is nearly identical to that produced by the MTS Altair 
8800 system. Six sections of a 7404 are used for this delay to 
provide greater simplicity and higher reliability than a one- 
shot. The 8224 chip also provides the power-on reset function 
through use of a 4. 7K resistor and 33 uf capacitor connected 
to the reset input of the 8224. The power-on reset is applied to 
the 8080A and is applied to the POWER ON CLEAR line, pin 
99 on the back plane. 

The two BACK PLANE READY signals are ANDed and 
connected to the 8224 for synchronization with the Phase II 
clock before being connected to the 8080A chip. The INTER- 
RUPT line is connected directly to the 8080 A, while the HOLD 
REQUEST line is synchronized with the Phase II clock and 
then connected to the 8080A. 

The six processor status signals (SYNC WRITE, STROBE 
DATA BIT IN, READ STROBE, INTERRUPT ENABLED, 
HOLD ACKNOWLEDGED, and WAfT ACKNOWLEDGE) 
are all driven onto the back plane through 8T97 tri-state 
buffered drivers. These drivers may be disabled by the CON- 
TROL DISABLE line, pin 19 on the back plane. 

The +5 volts is regulated from the +8 volts by a 7805 integrated 
circuit regulator, while the -5 volts is regulated by a 5 volt zener 
and a 470 ohm resistor from the 16 volt bus. The +12 volts is 
regulated by a 12 volt Zener and connected to the +16 volt line 
by two 82 ohm 1/2 watt resistors in parallel. All voltages are 



filtered with .33 microfarad tantalum and disc ceramic capaci- 
tors. 



Note: These boards were made for front panel use even though 
the description says otherwise. The problem noted in the sche- 
matic is the lack ofMWRT, a signal indicating a memory write 
is in operation. Not all boards need or use this signal. I 
encountered this problem when attempting to interface to later 
versions ofS-100 boards that relied on this signal. The signal 
was generated however by a front panel circuit. The front 
panel contained switches to single step the CPU as well as 
providing other control signals and pull ups for lines not 
supported by the CPU card. An extra pull up resistor and 
Jumper were also added for similar reasons, but the exact 
number and type of changes needed will depend solely on the 
other type of cards used. In bringing up these older boards, 
you must check out ALL control signal lines on all cards used. 
Not all vendors used all lines as intended or as specified later 
in the IEEE 696 standard BDK. 



TCJ Center Fold 

The Computer Journal solicits reprintable sche- 
matics and documents for use in the center fold 
section. We prefer schematics that have been 
redrawn and reproduced using high quality sys- 
tems (CAD programs and laser printers). Many 
older schematics will not reproduce due to too 
small of print and folds that make pin numbers 
unreadable. Minor changes are acceptable if fol- 
lowed with a description of the why the schematic 
changes were needed and what problems were re- 
solved. Descriptions on disk of what and how the 
circuit works is desired but not always required. 
Send all enquiries and drawings to TCJ, PO Box 
535, Lincoln, CA 95648. 



Planned Center Folds are: 

- Big Board Z80 (Xerox and Kaypro early design). 

- IMSAI PIO and SIO S-100 boards 

- CCS 2422 disk controller 

- SD systems SBC300 single card Z80 S-100 con- 
troller 

- GIMIX 6809 CPU and Floppy DISK controller 
card for SS-50 bus 
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Dr. S-100 

By Herb R. Johnson 



Regular Feature 

Intermediate 

Vendor Review 



Greetings 

A good new year to you all! I just re- 
turned from Washington DC, where I 
wandered over to the Smithsonian col- 
lections of surplus computers, spacecraft, 
and so on. As the catalogs say, there was 
' 'too much to list here ! " ; I' 11 cover some 
of S-100 equipment (!) they have on 
display next time. 

This month, after answering some mail 
about S-100 and about the Z180-PC 
proposal, I'll discuss some of the major 
vendors of the S-100 equipment you are 
likely to find in your (or someone else's) 
basement. Again, there are too many 
vendors to list, so I'll wrap up with some 
"generic comments" on evaluating an 
S-100 system you might come across. 

Letters 

John Haugh of Shorewood WI, a collec- 
tor of Cromemco equipment, offers his 
services to help other users of this line of 
S-IOO computers. "After sending com- 
puters to my kids to help them in col- 
lege, I expect to build several 
Cromemco's for my grandchildren!". 
His systems range from simple CDOS 
boxes to fiill Unix systems, all pure 
Cromemco. Give him a call if you need 
a little help. 

Paul Herman of Paul F Herman Inc. 

wrote to congratulate me on this col- 
umn. He publishes Z-100 Lifeline for 
the Heath/Zenith Z-100 crowd, and sells 
a variety of hardware and software for 
this dual-processor IEEE-696 system 
(which I'll describe later in the colmnn). 
His newsletter plug hopes we cover Z- 
100 equipment: I'd encourage him and 
his readers to send me whatever they'd 



like to see: this column is not a sole- 
source effort! 

Paul offers a SCSI controller for $210, 
with software for the Z-100 (only) for 
$39.00 and its source code for $39.00 
more. If the TCJ readership is inter- 
ested, I could ask Paul to loan me a card 
and I'll see if it can be used for non- 
ZIOO systems. Paul has been in this 
business for many years, and the Heath 
crowd is a very loyal group, so keep Paul 
(and Heath/Zenith) in mind, We must 
note, in passing, that Heath Co. is finally 
dead: after several acquisitions, the back 
stock of all replacement parts were auc- 
tioned off in December and no Heath 
products are for sale. 

Got a long letter about S-lOO systems 
from David Drew of Newark DE. He 
was kind enough to write on his per- 
sonal history of building, debugging, and 
trading. Starting with ExpandoRAM (by 
Morrow, I think?) and SD Systems cards 
in 1979, today he has a N* (an abbrevia- 
tion for NorthStar) and other unnamed 
systems with "monstrous" 14-inch hard 
drives. Thanks for the letter, David: mind 
if I pubhsh it as a "testimonial"? 

The Z180-PC: What about MY Com- 
puter? 

TCJ editor Bill Kibler asked last issue 
if anyone was interested in our idea for 
a Z180-based IBM-PC bus compatible 
card, that would "talk to" other IBM- 
PC cards and thus replace the 8088- 
based motherboard. I've only had a few 
responses so far. One exchange came 
from TCJ advertiser Bill Roch of Elliam 
Associates. We discussed a Z180 design 
upgrade for the British Amstrad PCW. 
While it's not an S-100 system, it is a 
Z80-based machine that is popular in 



Europe and has a following here in the 
USA. We kind of decided it would not be 
cost-effective to compete with the up- 
grades that already exist (a common 
consideration!) but it gave me a chance 
to see the "guts" of a CP/M machine 
with ASIC's (i.e. big custom IC's) in- 
stead of TTL (i.e. a single custom IC 
instead of lots of little stock logic chips.) 

I'm hesitant to pursue a "Z180-PC" 
without more reader feedback. I don't 
want to compete with other Z180 ven- 
dors (who probably need the business, 
particularly if they service us hobbyists), 
nor try to build another kind of PC, 
which will scare away people who al- 
ready find the IBM PC and MS-DOS 
"too complicated". Finally, how do I 
deal with even trying to support many of 
the cards out there and keep my day job? 
As users, you'll have the same problem 
(or challenge, depending on your priori- 
ties). 

A simpler and cheaper solution may be 
a simple processor card with a few de- 
vices supported, with the ability to daugh- 
ter-card support hardware for other de- 
vices. (A "daughter card" attaches to a 
circuit board via a short jumper cable or 
a simple connector. Often it is designed 
well after the original product is in pro- 
duction as an afterthought.) Actually, 
I've had more correspondence for hard 
drive controllers adaptors than any other 
development project. A simple card could 
do this for several machines. No feed- 
back, no projects: readers, it's up to you! 

S-100 Manufacturer's Survey: The 
Way It Was 

Surprisingly, there are still a few ven- 
dors building IEEE-696 cards. 1 believe 
Compupro (sometimes called Viasyn) 
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and Cromemco are still selling systems; 
maybe they build a few cards when the 
stockroom is empty. However, these are 
80386 systems for thousands of dollars, 
no schematics provided, etc. In short, 
not for hackers! They still charge hun- 
dreds of $$ for old cards too, so there is 
no reason for you to call them. Keep in 
mind that some users of these systems 
are still in business, doing business things 
with these computers! Consequently, the 
system vendors are still able to com- 
mand original price since system users 
must either pay or upgrade! So, you 
can try to call the original vendors, but 
don't expect more than (maybe) free 
documentation. 

"For the rest of us," we must get our 
systems and cards used. You may find 
yourself in a position to even choose a 
system amongst several at a flea market, 
or at a surplus outlet. So many systems, 
so little money! So this month, let's 
walk down memory lane with the Ghost 
of Computers Past for a tour. 

IMSAI and Altair systems are among 
the oldest S-100 systems built. Early 
versions had the front panel for ' 'conve- 
nient" access to address and data lines 
for debugging and programming. In the 
old days, peripherals were unavailable 
at any sane price so blinking lights and 
toggle switches were themselves a 
miracle! Later systems became more 
"personal", even "PC" like. Positives: 
potential antique value, "classic" sys- 
tems. Front panels seem popular and 
useful to some. Negatives: 8080/8085 
class only, minimal functions per card, 
parts very obsolete. 

Compupro systems vary from simple 
8085's and Z-80's to 68000's and 
80386's. Their static RAM cards vary 
likewise in size, and they had a variety 
of peripheral controllers for floppy and 
hard disk of all ages. Note: their later 
systems used cards without voltage regu- 
lators, relying on bus power for +/-5 
volts and for +/- 12 volts. Positives: their 
cards are well-marked, professionally 
built and laid out. You can look at any 
card and, if you know chip functions by 
name, figure it out. Negatives: some of 
their cards went through a lot of revi- 



sions, and early revisions were flaky (e.g. 
disk controllers). 

Cromemco systems also cover a range 
of technolog>'. They produced a number 
of IMSAI-class S-100 cards and sj's- 
tems, including a copycat (relabeled?) 
IMSAI. Later they also went IEEE-696 
and built some fancier systems that com- 
peted with IBM-PC's for quite a while 
(as did Compupro). Positives: well- 
manufactured cards. Docs were complete 
and readable. Negatives: incredibly 
heavy mainframes! 

The Heath/Zenith Z-100 was 
"strongly" derived from the Compupro 
8/16 design, which also uses an 8085/ 
8088 processor pair. The motherboard 
has 6 IEEE-696 slots, the dual proces- 
sors as mentioned, 172K of RAM (3 X 
64K), serial and parallel ports, and a 
daughter board color/mono video card. 
The slots held a disk controller (5" and 
8" drives supported), and the case had 
two 5" floppies or one floppy and one 
hard drive which required a pair of con- 
troller cards, one for the slot and one on 
the drive. One model included a mono 
monitor as part of the unit. 

Positives: Docs, docs, docs! and current 
support from a number of third parties. 
Also, a lot of these were sold to the 
military, and are now appearing in sur- 
plus! Negatives: no Z-80 capability. The 
units with internal monitors are a bear 
to ship! I broke two CRT's at the tube 
socket (the glass nipples pop off). Write 
to me for details. 

Northstar systems were popular as busi- 
ness systems, especially with their op- 
tional wooden cover. I don't think they 
built to IEEE-696, and the Northstar 
Horizons I've seen were all based on 
hard sectored floppy disk controllers! 
Still, they also have had a loyal follow- 
ing. By the way, they also built a non-S- 
100 system in a terminal-like package 
called the Advantage, Positives: seem 
reliable. Negatives: hard-sectored flop- 
pies. 

Ithaca Audio or Ithaca Intersystcms 

was another long-standing vendor. They 
built the prettiest front-panel system of 
all! Their docs are OK, and their cards 



all seem reasonably functional. I espe- 
cially like their 8K static RAM cards, 
covered with 64 2 I02's. They often work 
at 3 or 4 MHz, and were a design copied 
by many others in the old days. Posi- 
tives: availability. Negatives: none other 
than the ravages of age and old designs. 



Generic comments 

About identifying cards in general.... 
Know your chips! If you can identify 
floppy controller chips, serial chips, par- 
allel chips, memory chips, and so on by 
name, you are halfway to a full under- 
standing of any computer card! Also 
know S-100 cards by shape and size, 
and know how to count edge connector 
pins. Make a full-scale card from card- 
board and mark off the pin functions. 
Use these valuable and vital clues to 
determining function and worth of any 
card you find. You can learn about old 
chips by reading books and docs on older 
systems and noting the common chips: 
check your local library, your friend's 
basements, etc. (If there is interest, I'll 
create a list: call or write for details!) 

Specific examples: Avoid dynamic RAM 
cards if you can, especially cards built of 
1 6K or 4K DRAMS . The older the floppy 
disk controller chip, the less reliable and 
flexible the card. Look at bus pins 20 
and 70: if they are shorted to ground, the 
card is not designed to work with a front- 
panel (IMSAI/ALTAIR) system (but it 
might if you cover those pins). Check 
pins 61 through 64: (address lines A20- 
A23) if they are in use, the card is prob- 
ably near IEEE-696. 

The Ultimate Hint about IC's: learn to 
read date codes. They are usually a 
number for year and week of the year. 
Examples are 8412 (for the 12th week of 
1984) or 732 (for the 32nd week of 1987 
or 1977: you decide). Most boards have 
chips dated within a year or two. The 
boards themselves will have a copyright 
date too: this should help. 

Finally, for a detailed tour of vendors 
and cards, you might write or call for my 
catalog, which lists cards by vendor 
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name. Send $1 plus SASE for the latest 
on these late systems! 

Next Time 

What is your favorite vendor? Do you 
have something good or bad to say about 
S-100 manufacturers or their products? 
Send your comments to me directly, and 
if the volume warrants I'll discuss it next 
time. Alternatively, I'd like to answer 
the simplest question about S-100 sys- 
tems: what is the bus? Why have a bus, 
how does it work, and so on. The general 



discussion will apply to all bus-based 
systems, even those white MS-DOS 
bricks I've heard about recently, so at- 
tendance is open to all. 

References 

Heath/Zenith ZIOO systems: Paul F 
Herman Inc, 9317 Amazon Drive, New 
Port Richey, FL 34655. orders: 800-346- 
2152 other business 813-376-5457. 

Cromemco support: John J Haugh, MD, 
4205 North Newhall St, Shorewood WI 
53211. 



Amstrad PCW support, sales: Bill 
Roch, Elliam Associates, PO Box 2664, 
Atascadero CA 93423. (805) 466-8440. 

To get the full list of all references to 
date, send $1 plus SASE to me. Herb 
Johnson, for the ever-updated list of S- 
100 sources! Love letters are also accept- 
able. Bill Kibler prefers that correspon- 
dence to this column go directly to me, 
to expedite my response. That address 
again, CN 5256 #105, Princeton NJ 
08543. Or call (609) 588-5316 and ask 
for "Dr. S-100." 



CLASSIFIED, FOR SALE and WANTED 



Amstrad (c) PCW SIG: $9 for 6 bi- 
monthly newsletters dealing with the 
most popular CP/M machines still in 
production. Learn where to buy 3" 
discs, how to add 3.5 and 5.25 drives 
and where to buy the 8 MHz Sprinter 
board with room for 4 Meg of RAM. 
Make checks out to Al Warsh, 275 1 
Reche Cyn Rd #93, Colton, CA 92324. 

For Sale: GIMIX 6809 SS-50 floppy 
disk controllers. Have six to sell at 
$25 each plus shipping ($5). Bill at 
TCJ (800) 424-8825. 

WANTED: Modula-2 (Borland Prod- 
uct) for CP/M, originally marketed 
thru Echelon, Inc. Manual and Disks 
are needed. Apple II/CPM disk for- 
mat preferred but not essential. Call 
Norman Leet at (513) 864-2261 or 
leave message at Z-node #3 or 
CompuServe Mail (ID: 70200,144). 
Snail Mail address: 840 Hunter Rd. 
AptL,Enon, OH, 45323. 

Wanted Circuits of ADM3A and 
ADM5 dumb terminals (and with 
board layouts if possible). I am tempted 
to modify these to be a CP/M com- 
puter by adding to the circuitry. An- 
swers to J. S. Butler, 16 Uphill Drive, 
London NW9 OBU, England. 

Wanted: CP/M Astrology program, 
contact: Leon Brown, 144 Brewester 
Rd., Jewett City, CT 06351. 



Wanted: Information, manuals, etc. for 
DATAVUE DV-80 373M2 Multiuser 
system with 15 Mbyte Hard drive. Unit 
currently down, needs reformatting of 
hard drive, maybe boot disk for floppy? 
Any help getting back running would be 
appreciated. Alwyn Stockey, G3EKE/ 
W7, P.O. Box 1764, Sisters, OR 97759. 

Wanted: Will pay for Cromemco SCC 
Z80 cards. Need for on going commer- 
cial use. Also looking for RS 488 S-100 
cards?? Contact M. Schmidt (408) 432- 
1150 or Mark Tech Lazer Inc. 221 ID 
Fortune Dr. San Jose, CA 95131-1806. 

Wanted: Help/Information on making 
"MAGIC SAC" and "Translator 
ONE" work with Atari ST. These con- 
vert the Atari ST into an Macintosh. 
Have version 4.52 and 5.91 of software. 
Gets to Mac screen then dies and have 
trouble with disk formats. Also inter- 
ested in turning "Translator" into CP/ 
M system (has Z180)??? Contact Bill at 
TCJ (800) 424-8825. 

Wanted: Information or where abouts of 
source code and internal information to 
"POOR MAN'S NETWORK" by 
Anderson Techno Products of Ottawa, 
Ontario, Canada. This is network soft- 
ware for CP/M systems. Have used it 



with Xerox, S-100, and Superbrains 
over serial lines. Allows remote and 
background operation of second com- 
puter. I have an official version, are 
they still in business?? Contact Bill at 
TCJ (800) 424-8825. 

Wanted: Looking for CP/M68K or 
BIOS code for SAGE/STRIDE n. May 
be a UNIX version available as well. 
Bill at TCJ (800) 424-8825 

The Computer Journal classified sec- 
tion is for items FOR SALE. The 
price is based on Nuts & Volts rates. 
If you currently have a Nuts & Volts 
ad just send us a copy of the invoice 
and we will print the ad for the same 
price. 

Classified ads are on a pre-paid basis 
only. The rate is $.30 per word for 
subscribers, and $.60 per word for 
others. There is a minimum $4.50 
charge per insertion. 

Support wanted is a free service to our 
readers who need to find old or miss- 
ing documentation or software. No 
For Sale items allowed, however ex- 
changes or like kind swapping is per- 
mitted. Please limit your requests to 
one type of system. Call TCJ at (800) 
424-8825 or drop a card to TCJ, P.O. 
Box 535, Lincoln, CA 95648. 
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Regular Feature 

Kaypro Support 

Versions of Kaypros 



Mr. Kaypro 

By Charles B. Stafford 



In the last issue, we talked about moving 
the reset button from the back, to the 
front panel, where it might be more use- 
ful. A similar project with the video 
brightness control was hinted at. Neither 
of these modifications are "model' ' sen- 
sitive, but some in the future may be, and 
it might be nice to be able to identify 
your particular machine for other pur- 
poses as well. The following discussion 
may shed some light on the vintage of 
your treasured toy. 

About the time that Adam Osbourne 
decided that Apples were too expensive 
and elitist, and embarked on the enter- 
prise that produced the Osbourne 1, 
Andrew Kay, owner. President and Chief 
Potentate of Non Linear Systems, Inc. 
decided that it would be really neat, if 
the technicians who used his test equip- 
ment in the field, had a portable com- 
puter they could interface with almost 
any kind of system. This would make 
trouble-shooting much easier. Of course, 
he couldn't predict what systems those 
technicians might want to work on, so 
this computer would have to be easily 
modifiable, have a fairly complete pro- 
gramming language, be easy to trans- 
port out into the field, AND come with 
all the software a technician could ever 
want !! 

Thus was born the KayComp computer. 
It was a single board design, using readily 
available components (for repair pur- 
poses), had an integral 9 inch green 
monitor, and was housed in an alumi- 
num case with a suitcase handle that 
would fit under a standard airline seat. 
In fact, with minor differences, that origi- 
nal design was used throughout the en- 
tire production of CP/M based comput- 
ers and for the first MS-DOS machines. 



(For you aficionados, the sole exception 
is the Robie.) 

The name had to be changed early on, 
because there turned out to be another 
computer (much larger) that had an ear- 
lier claim to the name, and Andrew's 
child became the Kaypro. The first model 
had vertical drives, and was only pro- 
duced for a short time, then came the 
Kaypro II, which stored 200 kilobytes of 
data on each of the TWO Diskette Drives! 
It also had 64 kilobytes of random access 
memory, (you had to do an expensive 
upgrade to get that much on an Apple). 
AND it cost less than $2000, and had 
more software with it than you could 
ever use. 

Diskettes cost about $2.00 each and the 
initial decision was whether to buy more 
than 2 diskettes. How long would it take 
to fill them up ? 

Over the next few years came a succes- 
sion of improvements, double density 
diskette drives, a hard drive model, ru- 
dimentary graphics, a universal board 
design, a co-processor (courtesy of SWP), 
a real time clock, and finally a built-in 
modem, all housed of course, in a case 
that looked like Darth Vader's lunch 
box. 

Since they all looked similar, and had 
similar names, (FCaypro IV vs Kaypro 4) 
the differences although significant be- 
came blurred. The only reliable way to 
determine what you really have is to 
remove the hood and look at the "as- 
sembly" numbers silk screened on the 
main board and the labels on the moni- 
tor roms. The table on the following 



page lists the "stock" configurations as 
they left the factory. 

Fortunately for Andrew's technicians, 
and incidentally us, all of the Kaypros, 
except the Robie, have the same alumi- 
num case, with different paint and in the 
case of the K-lOs only one half-height 
floppy drive space. We are fortunate, 
because aluminum lends itself to rela- 
tively easy, accurate, modifications, such 
as fans and mounting holes for non- 
standard power supplies, and doesn't 
deteriorate significantly with age and 
ultra-violet radiation like plastic. 

Now that your treasure can be accurately 
identified, repairs and modifications 
should be much less traumatic and 
projects much more easily undertaken. 
May the FORCE be with you! 

BITES: 

Note the spelling, in this case, the word 
stands for Benefits, Ideas, Techniques, 
Experiences, and Serendippities. It is my 
fervent hope that this area will become 
a repository for some of the shortcuts I 
devise, but more importantly, for your 
contributions. I'm sure that most of you 
readers have developed sneaky ways to 
do things that I wouldn't think of in a 
million years, and I as well as the rest of 
our readers would love to BENEFIT from 
your labors. Here's a few I've run into. 

PERFECT WRITER and the TurboRom 
If you install the TurboRom exactly as 
the instructions say, you'll never run 
into this, but if you get excited and can't 
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wait to try the new operating system, 
it'll bite you. 

Symptoms; 

Perfect Writer will run just fine in the 
"edit" mode, windows and all. BUT, 
when it's time to print the fruit of your 
efforts, and you format the file, this 
message will appear "NOT ENOUGH 
MEMORY." 

I remember that sinking feeling well, 
thinking that I'd never get a document 
out of that damned machine. The size of 
the file didn't make any difference ei- 
ther. 

Problem; 

The formatter for Perfect Writer is loaded, 
and then loads the file specified at a 
certain address above itself, and 'way 
above that stakes out a "scratch" area. 
The top of the scratch area is about 57k 
up, and the initial operating system that 
is built for the TurboRom is a 56k sys- 
tem, so the program is right, there is 
apparently not enough memory, at least 
not that it knows about. 

The Cure; 

Somewhere around the last two steps in 
the installation procedure, the directions 
call for running a program called 
"PEEK". That small program will tell 
you what the maximum system size is 
based on your preferred disk buffer. Then 
the directions ask you to run 
MOVTURBO to create the max system. 
NOTE several of us have found that 
subtracting .25k from the figure that 
"PEEK" gives you, saves a lot of head- 
aches later if you make other hardware 
modifications. 

NON-STANDARD LABEL FRINTENTG 

SomeUme ago, 1 found myself with the 
task of printing 3/4 inch by 1/2 inch 
labels. I don't remember what the occa- 
sion was, a garage sale, or just a wifely 
desire to label a whole bunch of small 
boxes, but it was non-computer related, 
which didn't make me any more in- 
clined to do it by hand. Fortunately 
these particular labels came in an array 
5 wide by 7 deep (down), but even that 
is a real pain to put in the printer, and 
you lose the last three rows ( BEEP, 
paper out). It took a while, but I finally 



Model 



Versions of Kaypro computers 

CP/M version Mainboard ROM version 



K 1 


2.2U1 


81-294 


81-478-A 


K2X/MTC 


2.2U1 


81-580 


81-478-A 


K2X 


2.2H 


81-294 


81-292-A 


K2X 


2.2G 


81-294 


81-292-A 


K 2/84 


2.2G 


81-294 


81-292-A 


K 11/83 


2.2F 


81-240 


81-232 


K 11/83 


2.2F 


81-184 


81-242 


K 11/83 


2.2F 


81-110 ( 


obsolete) 8 1-149-C 


NEW 2 


2.2U1 


81-294 


81-478-A 


K4X 


2.2H 


81-297 


81-326-E 


K4X 


2.2G 


81-297 


81-326-E 


K4/84 


2.2H 


81-184 


81-292-A 


K 4/84+88 


2.2H 


81-184 


81-292-A SWP 


K4/84 


2.2G 


81-184 


81-292-A 


K 4/84+88 


2.2G 


81-184 


81-292-A SWP 


K 4/83+88 


2.2F 


81-240 


81-232-A SWP 


K4/83 


2.2F 


81-240 


81-232-A 


K4/83 


2.2F 


81-184 


81-232 


K 10/MTC 


2.2U1 


81-582 


81-478-A 


K 10 


2.2H 


81-181 


81-302-C 


K 10 


2.2G 


81-181 


81-302-C 


K 10 


2.2F 


81-181 


81-302 


K 10/83 


2.2D 


81-180 


81-188-N 


Robie 


2.2G 


81-296 


81-326-E 



note 1: The Robie and the K 4X use Drivetec high density diskette drives storing 
2.6mb each. They will also read DSDD. 

note 2: The only way to conveniently group storage capabilities of these beast, is 
by MAINBOARD number and model. The 81-1 10 board (the original K 11/83) was 
only capable (in it's virgin state) of single sided double density drives. All of the 
rest are capable (with some effort) of supporting double-sided double density 
drives. All of these machines except the K-10 series had two floppy drives. The 
K-10 series had one floppy drive and a 10 megabyte hard drive. A conversion was 
engineered by the Micro Cornucopia staff to convert the original K II to a K 4 
(double sided drives) and ADVENT had a decoder/personality board that allowed 
two floppies on a K 10. (these will be the subject of future "HOW-TO" articles.) 

note 3: ' 783 " is a model year designation; ' '/MTC ' indicates an onboard modem 
(300 baud) and a real time clock; "+88" indicates an 8088 coprocessor board 
installed, strictly generic MD-DOS that used the real Kaypro as a terminal. SWP 
was the manufacturer of the coprocessor board. 

note 4: The K 10 series and the ROBIE, as well as some "late model" dual drive 
machines had 85 watt power supplies. The rest had 65 watt power supplies, both 
of which were/are marginal. The major symptom of inadequacy is ' 'wavering' ' of 
the display when a drive is accessed. 
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figured it out. I used the word processor 
to create an array of text 5 across and 7 
down. Then I set the printer for con- 
densed (17cpi) and printed it. When I 
held the printout up to the light with the 
array of labels superimposed, it was ob- 
vious that the text needed some adjust- 
ment. Four iterations later it was perfect, 
now came the sneaky part. 1 set the top 
edge of the paper right at the top of the 
ribbon guide on the print head. (The 
actual reference doesn't matter as long 
as it's repeatable) Then using the "list" 
command, so that there weren't any 
strange unforeseen margin or format- 
ting instructions, I printed the pattern 
copy of the text. After removing the 
paper from the printer, I used "double 
stick" tape to fasten an array of blank 
labels directly over and in "register" 
with the text. Then 1 put the paper back 
in the printer, set the top of the paper 
right at the top of the ribbon guide on the 
print head, set the printer for condensed, 
and "lisf'ed the file. VIOLA, perfect 
labels 

NZCOM & LAZINESS 

When I first installed NZCOM, I main- 
tained named directories absolutely scru- 
pulously. Every time 1 needed a new 
area, I'd name it, build a new names.ndr 
file, load it and use NZBLITZ to build a 
new system image. That way I could 
find everything, right? Well yes, it 



worked, but after the "NEW" wore off, 
it became a real pain, or I became lazy, 
the result was the same, I just didn't do 
it. SO, I devised a new easier system. I 
just install the new software in a discreet 
area and use "S ALIAS" to create a 
"batch" file that will take me to the 
appropriate area, invoke the program and 
return me to the root directory when I'm 
finished. By doing this, moving all the 
"system" files into a different area, and 
using "SDZ" as an initial command 
line, only the alias files appear on the 
screen at boot-up as a menu of sorts. 
There are more elegant ways to provide 
menus, but this is just for me, and it's 
quick and simple, so I'm likely to keep 
up with it. An example follows: 



Letters.com 



a6: 



aO; 
sdz 



* this is the area where my word 

* processor is 

* invokes NewWord, my word 

* processor 

* takes me back to tlie root area 

* puts all the ahas filenames on the 

* screen again 



Like I said, not elegant, but it works!! 

REGULAR LABELS 

While rummaging around the other day, 
in search of heaven knows what, 1 came 
across my original printer, an Epson RX- 



80 that 1 paid a king's ransom for 'way 
back when. It was retired in favor of a 
Star NX- 1000, a year or so ago, dual 
paper feed, near letter quality, etc. you 
know the routine, but it occurred to me 
that it would be ideal for labels. Up to 
now, I've been removing the paper in 
the Star and loading tractor feed labels 
when I needed them, but it was such a 
nuisance that I avoided it whenever I 
could. Sound familiar? I now have the 
Epson on its own shelf, with a box of 
tractor feed labels on their own shelf 
beneath it, and an "A-B" switch box 
between the printers and the computer. 
I'm still using my Kaypro IV, by the 
way. The convenience is absolutely won- 
derful. I use a public domain program 
called LABELGEN. It was written in 
basic and compiled, and it's crude but 
effective. It asks for five lines of input, 
one at a time, and an "offset" and then 
prints as many labels as you asked for. 
The "offset" is really the left margin, 
and counting characters is up to you. I 
find myself using it not only for diskette 
labels, but for return address labels, ad- 
dresses, box labels, and sometimes just 
notes I want to stick on something. 



Enough of my blunders and techniques, 
I'd like to hear about some of yours. 1 
can be reached care of TCJ, or at 4000 
Norris Avenue, Sacramento, CA 95821. 
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MOVING FORTH 

by Brad Rodriguez 
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Intermediate Users 
Forth Kernel Design 



Part 1: Design Decisions in the Forth Kernel 

INTRODUCTION 

Everyone in the Forth community talks about how easy it is to 
port Forth to a new CPU. But like many "easy" and "obvi- 
ous" tasks, not much is written on how to do it! So, when Bill 
Kibler suggested this topic for an article, I decided to break 
with the great oral tradition of Forthwrights, and document the 
process in black and white. 

Over the course of these articles I will develop Forths for the 
6809, 8051, and Z80. I'm doing the 6809 to illustrate an easy 
and conventional Forth model; plus, I've already published a 
6809 assembler [ROD91,ROD92], and I'll be needing a 6809 
Forth for future TCJ projects. I'm doing the 8051 Forth for a 
University project, but it also illustrates some rather different 
design decisions. The Z80 Forth is for all the CP/M readers 
of TCJ, and for some friends with TRS-80s gathering dust. 

THE ESSENTIAL HARDWARE 

You must choose a CPU. I will not delve into the merits of one 
CPU over another for Forth, since a CPU choice is usually 
forced upon you by other considerations. Besides, the object of 
this article is to show how to move Forth to any CPU. 

You can expect the usual 16-bit Forth kernel (see below) to 
occupy about 8K bytes of program space. For a full kernel that 
can compile Forth definitions, you should allow a minimum of 
IK byte of RAM. To use Forth's block-management s>'stem for 
disk storage, you should add 3 Kbytes or more for buffers. For 
a 32-bit Forth model, double these numbers. 

These are the minimums to get a Forth kernel up and running. 
To run an application on your hardware, you should increase 
PROM and RAM sizes to suit. 

16 OR 32 BIT? 

The word size used by Forth is not necessarily the same as that 
of the CPU. The smallest practical Forth is a 16-bit model; i.e., 
one which uses 16-bit integers and 16-bit addresses. The Forth 
community calls this the "cell" size, since "word" refers to 
a Forth definition. 



8-bit CPUs almost invariably support 16-bit Forths. This 
usually requires explicit coding of double-byte arithmetic, al- 
though some 8-bit CPUs do have a few 16-bit operations. 

16-bit CPUs commonly run 16-bit Forths, although the same 
double-precision techniques can be used to write a 32-bit Forth 
on a 16-bit CPU. At least one 32-bit Forth has been written for 
the 8086/8088. 

32-bit CPUs normally run 32-bit Forths. A smaller Forth 
model rarely saves code length or processor time. However, 1 
know of at least one 16-bit Forth written for the 68000. This 
does shrink application code size by a factor of two, since high- 
level Forth definitions become a string of 16-bit addresses 
rather than a string of 32-bit addresses. (This will become 
evident shortly.) Most 68000s, though, have plenty of RAM. 

All of the examples described in this article are 16-bit Forths 
running on 8-bit CPUs. 

THE THREADING TECHNIQUE 

"Threaded code" is the hallmark of Forth. A Forth "thread" 
is just a list of addresses of routines to be executed. You can 
think of this as a list of subroutine calls, with the CALL 
instructions removed. CK'er the years many threading varia- 
tions have been devised, and which one is best depends upon 
the CPU and the application. To make a decision, you need to 
understand how they work, and their tradeoffs. 

Indirect Threaded Code (ITC) 

This is the classical Forth threading technique, used in fig- 
Forth and F83, and described in most books on Forth. All the 
other threading schemes are "improvements" on this, so you 
need to understand ITC to appreciate the others. 

Let's look at the definition of a Forth word SQUARE: 

: SQUARE DUP * ; 

In a typical ITC Forth this would appear in memory as shown 
in Figure 1. (The header will be discussed in a future article; 
it holds housekeeping information used for compilation, and 
isn't involved in threading.) 
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Assume SQUARE is encountered while executing some other 
Forth word. Forth's Interpreter Pointer (IP) will be pointing to 
a cell in memory ~ contained within that "other" word ~ 
which contains the address of the word SQUARE. (To be 
precise, that cell contains the address of SQUARE'S Code 
Field.) The interpreter fetches that address, and then uses it to 
fetch the contents of SQUARE'S Code Field. These contents 
are yet another address ~ the address of a machine language 
subroutine which performs the word SQUARE. In pseudo- 
code, this is: 

(IP) -> W fetch memory pointed by IP into "W" register 

...W now holds address of the Code Field 
IP+2 -> IP advance IP, just like a program counter 

(assuming 2 -byte addresses in the thread) 
(W) -> X fetch memory pointed by W into "X" register 

,..X now holds address of the machine code 
JP (X) jump to the address in the X register 

This illustrates an important but rarely-elucidated principle: 
the address of the Forth word just entered is kept in W. CODE 
words don't need this information, but all other kinds of Forth 
words do. 

If SQUARE were written in machine code, this would be the 
end of the story: that bit of machine code would be executed, 
and then jump back to the Forth interpreter - which, since IP 
was incremented, is pointing to the next word to be executed. 
This is why the Forth interpreter is usually called NEXT. 

But, SQUARE is a high-level "colon" definition ~ it holds a 
"thread", a list of addresses. In order to perform this defini- 
tion, the Forth interpreter must be re-started at a new location: 
the Parameter Field of SQUARE. Of course, the interpreter's 
old location must be saved, to resume the "other" Forth word 
once SQUARE is finished. This is just like a subroutine call! 
The machine language action of SQUARE is simply to push 
the old IP, set IP to a new location, run the interpreter, and 
when SQUARE is done pop the IP. (As you can see, the IP is 
the "program counter" of high-level Forth.) This is called 
DOCOLON or ENTER in various Forths: 

PUSH IP onto the "return address stack" 

W+2 -> IP W still points to the Code Field, so W+2 is 
the address of the Body! (Assuming a 2-byte 
address - other Forths may be different.) 
JUMP to interpreter ("NEXT") 

This identical code fragment is used by all high-level (i.e., 
threaded) Forth definitions! That's why a pointer to this code 
fragment, not the fragment itself, is included in the Forth 
definition. Over hundreds of definitions, the savings add up! 
And this is why it's called Indirect threading. 

The "return from subroutine" is the word EXIT, which gets 
compiled when Forth sees ';'. (Some Forths call it ;S instead 
of EXIT.) EXIT just executes a machine language routine 
which does the following: 



POP IP from the 

JUMP to interpreter 



'return address stack" 



Walk through a couple of nested Forth definitions, just to 
assiue yourself that this works. 

Note the characteristics of ITC; every Forth word has a one-cell 
Code Field. Colon definitions compile one cell for each word 
used in the definition. And the Forth interpreter must actually 
perform a double indirection to get the address of the next 
machine code to run (first through IP, then through W). 

ITC is neither the smallest nor the fastest threading technique. 
It may be the simplest; although DTC (described next) is really 
no more complex. So why are so many Forths indirect- 
threaded? Mainly because previous Forths, used as models, 
were indirect-threaded. These days, DTC is becoming more 
popular. 

So when should ITC be used? Of the various techniques, ITC 
produces the cleanest and most elegant definitions ~ nothing 
but addresses. If you're attuned to such considerations, ITC 
may appeal to you. If your code fiddles around with the insides 
of definitions, the simplicity and uniformity of the ITC repre- 
sentation may enhance portability. ITC is the classical Forth 
model, so it may be preferred for education. Finally, on CPUs 
lacking a subroutine call instruction ~ such as the 1802 - ITC 
is often more efficient than DTC. 

Direct Threaded Code (DTC) 

Direct Threaded Code differs from ITC in only one respect: 
instead of the Code Field containing the address of some 
machine code, the Code Field contains actual machine code 
itself 

I'm not saying that the complete code for ENTER is contained 
in each and every colon definition! In "high-level" Forth 
words, the Code Field will contain a subroutine call , as shown 
in Figure 2. Colon definitions, for instance, will contain a call 
to the ENTER routine. 

The NEXT pseudo-code for direct threading is simply: 

(IP) -> W fetch memory pointed by IP into "W" register 

IP+2 -> IP advance IP (assuming 2-byte addresses) 
JP (W) jump to the address in the W register 

This gains speed: the interpreter now performs only a single 
indirection. On the Z80 this reduces the NEXT routine ~ the 
most-used code fragment in the Forth kernel ~ from eleven 
instiiictions to seven! 

This costs space: every high-level definition in a Z80 Forth (for 
example) is now one byte longer, since a 2-byte address has 
been replaced by a 3-byte call. But this is not universally true. 
A 32-bit 68000 Forth may replace a 4-byte address with a 4- 
byte BSR instruction, for no net loss. And on the Zilog SuperS, 
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which has machine instructions for DTC Forth, the 2-byte 
address is replaced by a 1-byte ENTER instruction, making a 
DTC Forth smaller on the SuperS! 

Of course, DTC CODE definitions are two bytes shorter, since 
they no longer need a pointer at all! 

I used to think that high-level definitions in DTC Forths 
required the use of a subroutine call in the Code Field. Frank 
Sergeant's Pygmy Forth [SER90] demonstrates that a simple 
jump can be used just as easily, and will usually be faster. 

Guy Kelly has compiled a superb review of Forth implemen- 
tations for the IBM PC [KEL92], which I strongly recommend 
to ^ Forth kernel writers. Of the 19 Forths he studied, 10 used 
DTC, 7 used ITC, and 2 used subroutine threading (discussed 
next). I recommend the use of Direct-Threaded Code over 
Indirect-Threaded Code for all new Forth kernels. 

Jump to NEXT, or code it in-line? 

The Forth inner interpreter, NEXT, is a common rouUne to all 
CODE definitions. You might keep just one copy of this 
common routine, and have all CODE words jump to it. (Note 
that you Jump to NEXT; a subroutine Call is not necessary.) 

However, the speed of NEXT is crucial to the speed of the 
entire Forth system. Also, on many CPUs, the NEXT routine 
is quite short; often only two or three instructions. So it may 
be preferable to code NEXT in-line, wherever it is used. This 
is fi-equently done by making NEXT an assembler macro. 

This is a simple speed vs. space decision: in-line NEXT is 
always faster, but almost always larger. The total size increase 
is the nimiber of extra bytes required for in-line expansion, 
times the number of CODE words in the system. Sometimes 
there's no tradeoff at all; in a 6809 DTC Forth, an in-line 
NEXT is shorter than a Jump instruction! 

Subroutine Threaded Code (STC) 

A high-level Forth definition is nothing but a list of subroutines 
to be executed. You don't need interpreters to accomplish this; 
you can get the same effect by simply stringing a list of 
subroutine calls together. 

SQUARE: CALL DUP 

CALL * ; or a suitable alphanumeric name 
RET 

See Figure 3 . This representation of Forth words has been used 
as a starting point to explain Forth threading techniques to 
assembly language programmers [KOG82]. 

STC is an elegant representation; colon definitions and CODE 
words are now identical. "Defined words" (VARIABLES, 
CONSTANTS, and the like) are handled the same as in DTC 



~ the Code Field begins with a jump or call to some machine 
code elsewhere. 

The major disadvantage is that subroutine calls are usually 
larger than simple addresses. On the Z80, for example, the size 
of colon definitions increases by 50% ~ and most of your 
application is colon definitions! Contrariwise, on a 3 2 -bit 
68000 there may be no size increase at all, when 4-byte ad- 
dresses are replaced with 4-byte BSRs. (But if your code size 
exceeds 64 K, some of those addresses must be replaced with 6- 
byte JSRs.) 

Subroutine threading may be faster than direct threading. You 
save time by not having an interpreter, but you lose time 
because every reference to a Forth word involves a push and 
pop of a return address. In a DTC Forth, only high-level words 
cause activity on the return stack. On the 6809 or Zilog 
Supers, DTC is faster than STC. 

There is another advantage to STC: it dispenses with the IP 
register. Some processors ~ like the 8051 - are desperately 
short of addressing registers. Eliminating the IP can really 
simplify and speed up the kernel! 

The only way to know for sure is to write sample code. This 
is intimately involved with register selection, discussed in the 
next section. 

STC with in-line expansion; optimization; direct compila- 
tion 

On older and 8-bit CPUs, almost every Forth primitive involves 
several machine instructions. But on more powerful CPUs, 
many Forth primitives are written in a single instruction. For 
example, on the 32-bit 68000, DROP is simply 

ADDQ #4,An where An is Forth's PSP register 

In a subroutine-threaded Forth, using DROP in a colon defini- 
tion would result in the sequence 

BSR ... 

BSRDROP > DROP: ADDQ #4,An 

BSR ... < RTS 

ADDQ is a two-byte instruction. Why write a four-byte sub- 
routine call to a two-byle instruction? No matter how many 
times DROP is used, there's no savings! The code is smaller 
and faster if the ADDQ is coded directly into the stream of 
BSRs. Some Forth compilers do this "in-line expansion" of 
CODE words [CUR93a]. 

The disadvantage of in-line expansion is that decompiling back 
to the original source code becomes very diflficult. As long as 
subroutine calls are used, you still have pointers (the subroutine 
addresses) to the Forth words comprising the thread. With 
pointers to the words, you can obtain their names. But once a 
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word is expanded into in-line code, all knowledge of where that 
code came from is lost. 

The advantage of in-line expansion - aside from speed and 
size ~ is the potential for code optimization. For example, the 
Forth sequence 



3 + 



would be compiled in 68000 STC as 

BSR LIT 
.DW 3 
BSR PLUS 

but could be expanded in-line as a single machine instruction! 
Optimizing Forth compilers is too broad a topic for this article. 
This is an active area of Forth language research; see, for 
instance, [SC089] and [CUR93b]. The final culmination of 
optimized STC is a Forth which compiles to "pure" machine 
code, just like a C or Fortran compiler. 

Token Threaded Code (TTC) 

DTC and STC aim to improve the speed of Forth programs, at 
some cost in memory. Now let's move the other direction from 
ITC, toward something slower but smaller. 

The purpose of a Forth thread is to specify a list of Forth words 
(subroutines) to be performed. Suppose a 16-bit Forth system 
only had a maximum of 256 different words. Then each word 
could be uniquely identified by an 8-bit number. Instead of a 
list of 16-bit addresses, you would have a list of 8-bit identifiers 
or "tokens," and the size of the colon definitions would be 
halved! 

A token-threaded Forth keeps a table of addresses of all Forth 
words, as shown in Figure 4. The token value is then used to 
index into this table, to find the Forth word corresponding to 
a given token. This adds one level of indirection to the Forth 
interpreter, so it is slower than an "address-threaded" Forth. 

The principal advantage of token-threaded Forths is small size. 
TTC is most commonly seen in handheld computers and other 
severely size-constrained applications. Also, the table of "en- 
try points" into all the Forth words can simplify linkage of 
separately-compiled modules. 

The disadvantage of TTC is speed: TTC makes the slowest 
Forths. Also, the TTC compiler is slightly more complex. If 
you need more than 256 Forth words, it's necessary to have 
some open-ended encoding scheme to mix 8-bit and larger 
tokens. 

I can envision a 32-bit Forth using 16-bit tokens, but how many 
32-bit systems are size-constrained? 



Segment Threaded Code 

Since there are so many 8086 derivatives in the world, segment 
threading deserves a brief mention . Instead of using " normal ' ' 
byte addresses within a 64K segment, paragraph addresses are 
used. (A "paragraph" is 16 bytes in the 8086.) Then, the 
interpreter can load these addresses into segment registers, 
instead of into the usual address registers. This allows a 16- 
bit Forth model to efficiently access the fiill megabyte of 8086 
memory. 

The principal disadvantage of segment threading is the 16-byte 
"granularity" of the memory space. Every Forth word must 
be aligned to a 16-byte boundary. If Forth words have random 
lengths, an average of 8 bytes will be wasted per Forth word. 

REGISTER ALLOCATION 

Next to the threading technique, the usage of the CPU's reg- 
isters is the most crucial design decision. It's probably the most 
difficult. The availability' of CPU registers can determine what 
threading technique can be used, and even what the memory 
map will be! 

The Classical Forth Registers 

The classical Forth model has five "virtual registers." These 
are abstract entities which are used in the primitive operations 
of Forth. NEXT, ENTER, and EXIT were defined eariier in 
terms of these abstract registers. 

Each of these is one cell wide - i.e., in a 16-bit Forth, these are 
16-bit registers. (There are exceptions to this rule, as you will 
see later.) These may not all be CPU registers. If your CPU 
doesn't have enough registers, some of these can be kept in 
memory. I'll describe them in the order of their importance; 
i.e., the bottom of this list are the best candidates to be stored 
in memory. 

W is the Working register. It is used for many things, 

including memory reference, so it should be an address regis- 
ter; i.e., you must be able to fetch and store memory using the 
contents of W as the address. You also need to be able to do 
arithmetic on W. (In DTC Forths, you must also be able to 
jump indirect using W.) W is used by the interpreter in every 
Forth word . In a CPU having only one register, you would use 
it for W and keep everything else in memoty (and the system 
would be incredibly slow). 

IP is the Interpreter Pointer. This is used by every Forth 

word (through NEXT, ENTER, or EXIT). IP must be an 
address register. You also need to be able to increment IP. 
Subroutine threaded Forths don't need this register. 

PSP is the Parameter Stack (or "data stack") Pointer, 
sometimes called simply SP. I prefer PSP because SP is 
frequently the name of a CPU register, and they shouldn't be 
confused. Most CODE words use this. PSP must be a stack 
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pointer, or an address register which can be incremented and 
decremented. It's also a plus if you can do indexed addressing 
from PSP. 

RSP is the Return Stack Pointer, sometimes called simply 
RP. This is used by colon definitions in ITC and DTC Forths, 
and by aU words in STC Forths, RSP must be a stack pointer, 
or an address register which can be incremented and 
decremented. 

If at all possible , put W, IP, PSP, and RSP in registers. The 
virtual registers that follow can be kept in memory, but there 
is usually a speed advantage to keeping them in CPU registers. 

X is a working register, not considered one of the ' 'clas- 

sical" Forth registers, even though the classical ITC Forths 
need it for the second indirection. In FTC you must be able to 
jump indirect using X. X may also be used by a few CODE 
words to do arithmetic and such. This is particularly important 
on processors that cannot use memory as an operand. For 
example, ADD on a Z80 might be (in pseudo-code 

POPW POPX X+W->W PUSHW 

Sometimes another working register, Y, is also defined. 

UP is the User Pointer, holding the base address of the 
task's user area. UP is usually added to an offset, and used by 
high-level Forth code, so it can be just stored somewhere. But 
if the CPU can do indexed addressing from the UP register, 
CODE words can more easily and quickly access user vari- 
ables. If you have a surplus of address registers, use one for UP. 
Single-task Forths don't need UP. 

X ~ if needed ~ is more important to keep in register than UP. 
UP is the easiest of the Forth virtual registers to move into 
memory. 

Use of the Hardware Stack 

Most CPUs have a stack pointer as part of their hardware, used 
by interrupts and subroutine calls. How does this map into the 
Forth registers? Should it be the PSP or the RSP? 

The short answer is, it depends . It is said that the PSP is used 
more than the RSP in ITC and DTC Forths. If your CPU has 
few address registers, and PUSH and POP are faster than 
explicit reference, use the hardware stack as the Parameter 
Stack. 

On the other hand, if your CPU is rich in addressing modes ~ 
and allows indexed addressing - there's a plus in having the 
PSP as a general -purpose address register. In this case, use the 
hardware stack as the Return Stack. 

Sometimes you do neither! The TMS320C25's hardware stack 
is only eight cells deep ~ all but useless for Forth. So its 
hardware stack is used only for interrupts, and both PSP and 



RSP are general-purpose address registers. (ANS Forth speci- 
fies a minimum of 32 cells of Parameter Stack and 24 cells of 
Return Stack; I prefer 64 cells of each.) 

You will occasionally encounter the dogma that the hardware 
stack "must be" the Parameter Stack, or "must be" the 
Return Stack. Instead, code some sample Forth primitives, 
such as 

SWAP OVER @ ! + 0= 

and see which approach is smaller or faster. (DUP and DROP, 
by the way, are no test - they're usually trivial.) 

Occasionally you reach strange conclusions! Gary Bergstrom 
has pointed out that a 6809 DTC Forth can be made a few 
cycles faster by using the 6809 user stack pointer as the IP; 
NEXT becomes a POP. He uses an index register for one of 
Forth' s stacks. 

Top-Of-Stack in Register 

Forth' s performance can be improved considerably by keeping 
the top element of the Parameter Stack in a register! Many 
Forth words (such as 0=) then don't need to use the stack. 
Other words still do the same number of pushes and pops, only 
in a different place in the code. Only a few Forth words (DROP 
and 2DR0P) become more complicated, since you can no 
longer simply adjust the stack pointer - you have to update the 
TOS register as well. 

There are a few rules when writing CODE words; 

A word which removes items from the stack must pop 
the "new" TOS into its register. 

A word which adds items to the stack must push the 
"old" TOS onto the stack (unless, of course, it's 
consumed by the word). 

If you have at least six cell-size CPU registers. I recommend 
keeping the TOS in a register. I consider TOS more important 
than UP to have in register, but less important than W, IP, PSP, 
and RSP. (TOS in register performs many of the functions of 
the X register.) It's useful if this register can perform memory 
addressing. PDP-IIs, Z8s, and 68000s are good candidates. 

Nine of the 19 IBM PC Forths studied by Guy Kelly [KEL92] 
keep TOS in register. 

I think this innovation has been resisted because of the false 
beliefs that a) it adds instrucUons, and b) the top stack element 
must be accessible as memory. It turns out that even such 
words as PICK, ROLL, and DEPTH are trivially modified for 
TOS-in-register. 

What about buffering two stack elements in registers? When 
you keep the top of stack in a register, the total number of 
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operations performed remains essentially the same. A push 
remains a push, regardless of whether it is before or after the 
operation you're performing. On the other hand, buffering two 
stack elements in registers adds a large number of instructions 
-- a push becomes a push followed by a move. Only dedicated 
Forth processors like the RTX2000 and fantastically clever 
optimizing compilers can benefit from buffering two stack 
elements in registers. 

Some examples 

Figure 5 has the register assignments made by Forths for a 
number of different CPUs. Try to deduce the design decisions 
of the authors from this list. 

Narrow Registers 

Notice anything odd in the figure 5 list? The 6502 Forth - a 
16-bit model -- uses 8-bit stack pointers! 

It is possible to make PSP, RSP, and UP smaller than the cell 
size of the Forth. This is because the stacks and user area are 
both relatively small areas of memory. Each stack may be as 
small as 64 cells in length, and the user area rarely exceeds 128 
cells. You simply need to ensure that either a) these data areas 
are confined to a small area of memory, so a short address can 
be used, or b) the high address bits are provided in some other 
way, e.g., a memory page select. 

In the 6502, the hardware stack is confined to page one of RAM 
(addresses Olxxh) by the design of the CPU. The 8-bit stack 
pointer can be used for the Return Stack. The Parameter Stack 
is kept in page zero of RAM, which can be indirectly accessed 
by the 8-bit index register X. (Question for the advanced 



student: why use the 6502's X, and not Y? Hint: look at the 
addressing modes available.) 

In the 8051, you can use the 8-bit registers RO and Rl to 
address external RAM, provided that you explicitly output the 
high 8 bits of address to port 2, This allows a "page select" 
for two stacks. 

UP is different from PSP and RSP: it simply provides a base 
address; it is never incremented or decremented. So it's 
practical to supply only the high bits of this virtual register. 
The low bits must then be provided by whatever indexed 
addressing technique is used. For example, on the 6809, you 
can use the DP register to hold the high 8 bits of UP, and then 
use Direct Page addressing to access any of the 256 locations 
in this page. This forces all user areas to begin on an address 
xxOOh, which is no great hardship, and limits the user area to 
128 cells in length. 

On the 8086 you could conceivably use a segment register to 
specify the base address of the user area. 

PART II: BENCHMARKS 

By now it must seem that the answer to every design question 

is "code it and see." and at this point we lea\'e 

Brad till next issue when he continues our exploration into the 
insides of different Forth kernels. Brad uses code examples of 
kernel implementations on 6809, Z80, 8086, and 8051. 

In subsequent articles, Brad will look at: 

- design tradeoffs in the Forth header and dictionary search. 

- the logic of CONSTANTS, VARIABLES, and other data struc- 
tures. 









FIGURE 5. REGISTER ASSIGNMENTS 
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"SP" refers to the hardware stack pointer. "Zpage" refers to values kept 


in the 6502 's memory page zero, which are almost 


as useful as -- sometimes more useful than ~ values kept in registers; e.g., 


they can be used for memory addressing. ' 'Fixed' ' 


means that Payne's 8051 Forth has a single, immovable 


user area, and UP is a hard-coded constant. | 
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- The defining word mechanisms, CREATE.. ...;CODE and 
CREATE.....DOES>. 

- The assembler vs. metacompiler question. 

- The assembler and high-level code that comprises a Forth 
kernel. 

- multitasking modifications to the kernel. 

So stay tuned for the next exciting episode of "MOl'TNG 
FORTH", (editor) 
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After twelve years of designing and programming embedded 
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the side" as T-Recursive Technology, and can be contacted as 
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FIGURE 1. INDIRECT THREADED CODE 
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FIGURE 2. DIRECT THREADED CODE 
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FIGURES. SUBROUTINE THREADED CODE 
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FIGURE 4. TOKEN THREADED CODE 



token for 
SQUARt 



6 SQUARE link 



\ 



adrs 0^ machine 
»de for this wore 



token forjtoken for 
DUP 



token for 

EXIT 



TOKEN TABLE 



.address of SQUARE 



address of DUP 



etc. 



The Computer Journal / #59 



7^76 Computer Journal 

Micro Cornucopia Kaypro Disks 



K-22 
















K-25 










ZCPR 
















Z80 MACRO ASSEMBLER 




-22-DISK DOC 


10k 


1X14 


COM 


3k 


ZCPRIOS 


BEX 


6k 


25-DI3K DOC« 


3k 


README 


ZOO- 


8k 


lOeiHSTL SUB 


Ik 


EX14 


DOC 


6k 


ZCPR2 


HEX 


6k 


AZM-COM DOC 


4k 


UNSQ 


COM" 


12k 


lOZMSTAL SUB 


Ik 


emsTALL 


SUB 


Ik 


ZCPR2S 


HEX 


6k 


CRC COM" 


3k 


ZSC 


COM" 


8k 


2IHSIUX SUB 


Ik 


caaHSTAi 


SUB 


Ik 


ZCPR4 


BEX 


6k 


CRC DOC 


Ik 


280 


ZfiO- 


5k 


4IBSIALL SUB 


Ik 


ZCPR 


ASM 


53k 


ZCPR4S 


BEX 


6k 


CRCKLIST CRC« 


Ik 


Z80A 


ZQO« 


6k 


cue CCM 


3k 


ZCPR 


DOC 


5k 


zcpsox 


BEX 


6k 


MAC-AZM DOC 


5k 


Z80B 


ZQO" 


20k 


cue DOC 


Ik 


ZCPR 


MAN 


45k 


SCPRGXS 


HEX 


6k 


PHASE DOC> 


9k 


Z80C1 


ZQO« 


12k 


CBCKLISt CRC 


Ik 


ZCPRIO 


HEX 


ek 








PHASEl AZM> 


2k 


Z80C2 


ZgO" 


17k 



Contains ZCPR for all portable Kaypros (II, 4, 10, and 84). This version of 
ZCPR differs from the version on disk K-9 in a couple of ways. Mainly it 
fixes bugs in the way the old version handled control characters. The 
other improvement is that you may use a semi-colon as well as a colon to 
log onto a drive. In other words. A; has the same effect as A:. 
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BYE answers and hangs up the phone. It allows password access to 

specified drives and tiser areas. 

XMODEM allows the remote system to send and receive files. 

ZCPR (and Related Files) contain a protected version of ZCPR that 

prevents remote users from doing nasty things to your system (like erase 

all your files). 

INTTERM is a replacement for TERM.COM that lets your Kaypro act as 

a terminal for another system at high baud rates without dropping 

characters while scrolling. 
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KSTROKES Bill Forbes did an excellent job creating this keyboard 

translator simUar to Smartkey. You can define 8 keystrokes up to 63 

characters each. 

MBASIC GAMES This disk also contains 13 MBASIC games. 

USOPEN illustrates the fairway on the screen. Fore! 

DUCK An offshoot of aliens (pardon the pun). Hunter tries to shoot 

down ducks wlule ducks try to bomb the hunter. Much fairer than real 

life. 

CASTLE An adventtire game. 

UN2 allows you to UNprotect MBASIC (version 5.21 ) files. 

XREF produces a aoss reference by line number for the output of ASM 

and LASM files. 
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This disk contains a Z80 macro assembler that is the lucest I've seen in 

the public domain. 

Z80MR.COM The Z80 maao assembler. 

Z80MR.DOC is our documentation file crammed with examples and as 

much itiformation as 1 could come up with on this assembler. 

AZM-COM.DOC How to get from an assembly language source file to a 

COMfUe. 

PHASE.DOC How to get around the phase and dephase operators 

found in M80 fUes. 

MAC-AZM.DOC What you need to know to change .MAC (Microsoft's 

M80 assembler source files) to .AZM files. 

PHASEl. AZM Sample program described in PHASE.DOC 

Z80.COM The Crowe assembler extensivly modified to do conditionals, 

as well as a number of other new tricks. 
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EPROM runs the EPROM programmer published in Micro Cornucopia 

Issue #18. 

GETMON These programs get the code in your morutor ROM and load 

it at lOOh so that you can use the SAVE conunand to save the file for later 

disassembly or debugging. 

I/O-CAP captures console output and/or input to a disk file. 

DDTTOMAC works on the output of DDT.COM when using the "I" 

command to disassemble a .COM file. The output of DDT is captured 

using the program above. Then DDTTOMAC reworks the file so that it 

can be reassembled. 

KDEBUG One of the biggest drawbacks of the Kaypro is its lack of RAM 

resident monitor. This is a kludgey way of providing one, but anything is 

better than nothing. With this, "break points" can be included in the 

program under test to point to this monitor, and then memory can be 

examined or modified. 

COMPARE The best binary file compare I could find in the public 

donuiin. 

LOOK looks for a 1-9 byte sequence in memory. 

TELL shows you the CP/M landmarks. 

UNLOAD creates a .HEX file from a .COM file. 

CHREDIT A character set editor for 2716 character generator EPROMs. 

With this you can design your own character set and then bum it with 

your new EPROM programmer. 

CHRLIST.COM dumps your character set to the printer. 
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1TYPE.DOC Documentation file for EATYPE typing tutoriaL Read this 

filefiist! 

EATYPE EATYPE.BAS and EATYPE.COM are modified versions of the 

TTYPE program. They use the same data files and instructions but are 

much easier to list and install. 

TTYPE TTYPE.BAS may drive your printer nuts because of the carriage 

returns without line feeds. Most of these have been removed in EATYPE. 

TDRILL More typing drills. 

CRT TTYPE has to be set up for your CRT and for the keyboard STATUS 

and INPUT ports. 

ENVELOPE allows you to use your newly acquired tying skills to type 

addresses on envelopes. Happy Hunting and Pecking! 

FOGINDEX calculates the Gunning-Mueller Qear Writing Institute Fog 

Index of an ASQI file based on sentence and word length. 
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MDM730,COM is the main program developed by Irv Hoff and is one of 

the most versatile modem programs available bar none. This file has not 

been set up for Kaypro and is included for archival purposes only. 

KMIZOO.COM A ready to run version of MDM730.COM set up for the 

Kaypros. As presently set up, it has a phone directory, autodial, redial, 

touchtone, 1200 baud, 8 bit, 1 stop bit, and no parity check. 

KM300.COM Same as KM1200.COM except defaults to 300 baud rate. 

MDM730.DOC A very comprehensive explanation of the features of 

MDM730andKM1200. 

MKP4-10.ASM Overlay file containing assembly instructions to set up 

MDM730.COM to operate properly on Kaypro 11,4 & 10. 

M7NM-6 Overlay file containing assembly instructions to set up 

MDM730.COM to include the autodial telephone directory. 

M7FNK Program and documentation to allow you to change the 10 

function keys in MDM730.COM or KM1200.COM to whatever you like. 

M7LIB Program and documentation to allow you to change the phone 

numbers in the MDM730.COM or KM1200.COM autodial telephone 

directory. 

MLOAD21 A public domain version of CP/M's LOAD. 
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HORSERAC 


CHM* 


3k 


BJGAMB 


CHH* 


5k 


D 


CC«* 


3k 


HOaSERAC 


PAS* 


5k 


BJCAME 


PAS* 


10k 


oaoaz 


CHN* 


6k 


KEHO 


CHN* 


2k 


BLACKBOX 


CHN* 


4k 


DODGE 


PAS* 


12k 


KEHO 


PAS* 


5k 


BLACXBOX 


PAS* 


Sk 


SAMBfENU 


CHH* 


Ik 


MAKEFILE 


CHN* 


Ik 


BLOCK 


CHN* 


3k 


SAMEMENt) 


PAS* 


2k 


MAKEFILE 


PAS* 


2k 


BLOCK 


PAS* 


10k 


GAMES 


COM* 


Bk 


READNtIM 


PAS* 


Ik 


BOCGLR 


CHH* 


2k 


GAMES 


FAS* 


Ik 


WORDS 


DAT* 


2k 


BOCSLE 


PAS* 


4k 


GUESSIT 


CHN* 


Ik 








CHUCKLCK 


CHN* 


2k 


GUESSIT 


PAS* 


3k 









K-30 

TURBO PASCAL GAMES 



II 



30-DISK 


DOC* 


5k 


KISMET 


FAS* 


12k 


READHIM 


FAS* 


Ik 


ARTILLRY 


CHH* 


2k 


LANDER 


CHN* 


4k 


SNAKE 


CHM* 


4k 


ARTILLRX 


PAS* 


4k 


LANDER 


FAS* 


10k 


SHAKE 


PAS* 


8k 


CRC 


COM* 


31c 


LANDIHST 


DAT* 


2k 


STARS 


CHN* 


4k 


CRCKLIST 


CRC* 


21c 


NDMCNVRT 


CHH* 


2k 


STARS 


PAS* 


13k 


D 


COM 


3k 


miMCNVRT 


FAS* 


5k 


TELEPHOM 


CHM* 


2k 


GAMEMENU 


CHN* 


Ik 


OVERUNDR 


CHH* 


2k 


lELEFHON 


FAS* 


5k 


GAMEHENU 


PAS* 


2k 


OVEROHDR 


FAS* 


4k 


TWINKLE 


CHM* 


Ik 


GAMES 


CHH* 


Ik 


PASCAL 


CHN* 


Ik 


TWINKLE 


FAS* 


2k 


GAMES 


COM* 


8k 


PASCAL 


FAS* 


3k 


HTMPUS 


CHH* 


4k 


GAMES 


PAS* 


Ik 


PLIFE 


CHH* 


4k 


wtiMPns 


PAS* 


9k 


KISMET 


CHH* 


6k 


PLIFE 


FAS* 


9k 









More chained games with source in Turbo Pascal. 

K-31 

TURBO BULLETIN BOARD 



-31-DISK 

10GIH3TL 

lOIHSIAL 

2INSTALL 

31-DISK 

4IHSTALL 

BXE 

BYE 

BYEZCPR 

CRC 

CRCKLIST 



DOC 
SDB 
SUB 
SUB 
DOC 
SUB 
COM 
DOC 
DOC 
COM 
CRC 



2k 
Ik 
Ik 
Ik 
Ik 
Ik 
3k 
Ik 
9k 
3k 
2k 



D 
EX 

GIN5TALL 

GXIN3TAL 

RZCFRIOS 

IIZCPR2S 

RZCFR84S 

RZCPRGXS 

SYSMSG 

TBBS 

TBBS 



CON 
CON 
SUB 
SUB 
HEX 
HEX 
HEX 
HEX 
BBl 

can 

DOC 



3k 

3k 

Ik 

Ik 

Sk 

5k 

5k 

5k 

Ilk 

27k 

14k 



TBBS 

TBBSCCM 

TBBSHDR 

TBBSMSG 

TUTL 

TX3TL 

USQ 

XMODEM 

XMODEM 

ZCPRBLOC 



PAS 
INC 
INC 
INC 
COM 
PAS 
COM 
CON 
DOC 
COM 



Ilk 

8k 

4k 

10k 

27k 

13k 

2k 

3k 

3k 

Ik 



TBBS is the bulletin board program. Turbo Pascal source code included. 
TUTL maintains the bulletin board files (messages, users, and the log), 
BYE To set up your system for remote use, type BYE. When someone 
calls, BYE answers the phone and runs TBBS. 
XMODEM A program for sending or receiving files with TBBS. 

K-32 
FORTH-83 



32-DI3K DOC 2k 

CPU8080 BQK 9k 

CRC COM 3k 

CRCKLIST CRC Ik 

CUSTCM BQK 4k 



D CON 3k 

EXTEND80 BQK 9k 

r83 CCM 25k 

F83 DOC 10k 

KERNEL COM 12k 



META80 BQK 72k 
USQ COM 2k 
OTILITT BQK 3 6k 



Here we go— FORTH Heaven again! F83 is the Laxen and Perry 
FORTH-83 with some extensions. 



K-33 














UTILITIES 












33-DlSK DOC* 


2k 


HSHP2 


HLP* 


Ilk 


NULOTEIIN ASM* 


3k 


CRC CCM* 


3k 


N5WP2 


WS * 


28k 


SUPERZAP CCM* 


6k 


CRCKLIST CRC* 


Ik 


NSWP207 


COM* 


12k 


SUFERZAP DOC* 


Ilk 


D COM 


3k 


NSWP207 


DOC* 


3k 


VDO-KP COM* 


5k 


EDIT COM* 


2k 


NDLU 


DOC* 


40k 


VD023-KP DOC* 


13k 


EDIT DOC* 


13k 


NULOll 


CCM* 


15k 






HELP COM* 


2k 


NULDll 


NOT* 


2k 







NSWP207 The latest version of SWEEP, written by Dave Rand. NSWP 

allows you to tag files for copying, erasing, squeezing, unsqueezing, 

finding, and printing. 

NULUll Creates, manipulates, and extracts libraries. 

SUPERZAP A full screen disk editor at only 6K. 

VDO-KP A fast, mini-editor — small and easy to use. 

EDIT A utility to copy and edit files (text and binary). 
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K-34 
GAMES 



34-DI3IC 


DOC* 


7k 


DBLICK-V FQ8> 


8k 




COM 


12k 




MQC 


7k 


DOCTOR 


ELI* 


5k 




PQS 


6k 


C31C 


CGM« 


3k 


ru 


pgs. 


6k 


OTHELLO 


CCN 


17k 


CKCKLIST 


CSC* 


Ik 


EL2 


PCg. 


3k 




DOC 


Ik 


CSIBBMl 


CON* 


20k 


ELIU 


COM* 


13k 




FOR 


7k 




PQ2« 


3k 


ILIM 


DOC* 


8k 


PIP 


COM* 


8k 


CRIBBAGS 


PQ3« 


6k 


lUZA 


PQS* 


3k 


DSQ 


COM* 


10k 


CKIBBkCI 


PQS* 


Ilk 


rjuotcPM 


ELZ* 


2k 








DBUCK-V 


CCM« 


17k 


Tuamx 


ELI* 


2k 









Disk 34 contains five games along with source code. Turbo Pascal is the 

language of choice with the exception of OTHELLO, which is written in 

FORTRAN. OTHELLO will run only on 84 model Kaypros. 

CRIBBACE is, as you may have guessed, a computer version of the card 

gamecribbage. 

DBLICK-V Nicely done version of the venerable video game 

BREAKOUT. 

ELIZA allows conversation with your computer. 

GERMS is variation on LIFE. 

OTHELLO takes advantage of the video capabilities of the 84 model 

Kaypros. 

K-35 

SMALL C (Ver 2.1) COMPILER & SOURCE 



35-DISK 


DOC 


Ik 


ce2i 


c 


6k 


CCCM 


SUB* 


Ik 


MtSS 


c 


Ik 


CC22 


c 


9k 


CCCK 


SUB* 


Ik 


CAT 


c 


Ik 


CC3 


c 


2k 


cca< 


SUB* 


Ik 


CC 


COM 


29k 


CC31 


c 


8k 


CCRTL 


MUC* 


25k 


CC 


DEr 


8k 


CC32 


c 


6k 


CCKTL 


»L* 


3k 


CC 


DOC 


10k 


CC33 


c 


5k 


cue 


COM* 


3k 


CCl 


c 


6k 


CC4 


c 


Ik 


CRCXLIST 


CRC* 


2k 


cell 


c 


7k 


CC41 


c 


8k 


D 


COM* 


3k 


CC12 


c 


Bk 


CC42 


c 


9k 


UW 


C • 


2k 


CC13 


c 


8k 


ccc 


SUB 


Ik 


WO 


c • 


2k 


CC2 


c 


2k 


cccc 


SUB 


Ik 









Disk 35 is Fred Scacchitti's upgrade of the Small C compiler (Version 2.1) 

and includes source. 

This version requires Microsoft's M80/L80. 

K-36 

SMALL C LIBRARY 



36-DISK DOC* Ik 
CRC COM* 3k 
CRCKLIST CRC* Ik 



D COM 3k 
DELBR C<M' 13k 
SCLIBl LBR* 39k 



SCLIB2 LBR* 78k 



Disk 36 contains a library of 105 C functions. Most of these are desaibed 
in Jim Hendrix's Small C Handbook. 

K-37 

UTILITIES PRIMER 

37-DISK DOC* 2k 
CRC COM* 3k 
CRCKLIST CRC* Ik 
DBUSABST DOC* 28k 
DBUGIHST DOC* 10k 

Disk 37 contains three utilities. We've included assembler source code for 

DEBUG and DU-V86. 

DEBUG In Issue #25 of Micro Cornucopia, Richard Amyx wrote an article 

titled "Why I Wrote a Debugger." DEBUG is a beta test copy of his Z80 

debugger discussed in the article. 

DU-V86 The latest version of the disk utility DU allows you to view and 

edit any byte on a disk. 

VFILER Similar to SWEEP, VFILER performs the same basic file 

manipulations, but adds screen oriented displays. 



DEBCe 


CCM* 


4k 


VriLER COM* 


8k 


DEBUS 


Z80* 


52k 


VriLER DOC* 


3k 


DU-V86 


ASM* 


sek 


VriLERSC ASM* 


3k 


Dn-V86 


COM* 


8k 






DU-V86 


DOC* 


13k 







PLMRERl 


IOC 


7k 


PR0BE3 


PQS 


13k 


PROBE 


COM 


27k 


RXSCUX 


DOC* 


8k 


PROBE 


DQC 


23k 


RESCUE 


PQS* 


9k 


PROBE 


PQS 


Ik 


RXSCUE60 


COM* 


14k 


PROBEl 


PQS 


13k 


RZSCUIM 


COM* 


14k 


PR0BE2 


DQC 


6k 


USQ 


COM* 


2k 


PR0BE2 


PQS 


7k 









K-38 

PASCAL RUNOFF WINNERS FIRST— THIRD 

38-DISK DOC* 3k 

CRC COM* 3k 

CRCKLIST CRC* Ik 

PLAirSTRU DOC 5k 

PLANTER CON 17k 

PLAHTER DOC 4k 

PLAITTIR PQS 9k 

PROBE Rick Ryall's effort was the unanimous winner. His disk editor 
will view and edit sectors, find bad sectors, copy blocks to a new 
location, search for text strings, and feed the dog. 
RESCUE Steve Mitton's second place entry provides a painless search of 
memory for text lost due to whatever made your Kaypro crash. 
PLANTER Third place goes to Dennis Sprague. After the user describes 
the dimensions and number of sides of a wooden planter box, PLANTER 
draws (on 84 Kaypros) the required pieces and gives all dimensions 
necessary to build the box. 

K.39 

PASCAL RUNOFF WINNERS FOURTH-FIFTH 



39-DISK 


DOC* 


2k 


PAMPHLET 


PQS* 


9k 


VB-BLK2 


IQC* 


4k 


BUILDING 


FRE* 


2k 


SAMPLE 


IQ . 


7k 


VB-BLK3 


IQC* 


10k 


CHAPTER4 


FRE* 


2k 


SAMPLE 


OQT* 


7k 


VB30 


DQC* 


24k 


CHAPTERS 


rsE* 


2k 


TEST 


FRE* 


Ik 


VB30I 


COM* 


23k 


CLASROCM 


FRE* 


Ik 


USQ 


COM* 


2k 


VB30I 


DTA* 


5k 


CRC 


CON* 


3k 


VB 


000* 


10k 


VB30I 


Mse* 


3k 


CRCKIIST 


CRC* 


Ik 


VB 


C<M* 


17k 


VBDIRCFM 


IQC* 


3k 


HELP 


VB • 


7k 


VB 


PQS* 


2k 


VBDIRDOS 


IQC* 


3k 


PAMPHLET 


COM* 


Ilk 


VB-BLKl 


IQC* 


ek 









VB Written by Norman Saunders and Frances Coniglio, VB (Vocabulary 
Builder) teaches foreign language vocabulary. 

PAMPHLET Steve WUcox's fifth place finisher takes a Wordstar file and 
rearranges the pages in the proper order for printing a folded pamphlet. 

K.4O 

PASCAL RUNOFF WINNERS SIXTH PLACE 



40-DISK 


DOC* 


2k 


BOTTIBLD 


STR* 


2k 


CRCKLIST 


CRC* 


Ik 


BOTTI 


COM* 


25k 


BOTTIDEC 


INC* 


8k 


lOERROR 


me* 


2k 


BOTTI 


ERR* 


Ik 


BOTTI FRE 


IQC. 


6k 


PSESIDin 


BOT* 


15k 


BOTTI 


INS* 


24k 


BOTTIIHI 


IQC. 


5k 


PRESIDHT 


DSC* 


Ik 


BOTTI 


PAS* 


£k 


BOTTI INP 


INC* 


8k 


PRK8IDHT 


FRE* 


2k 


BOTTI 


DHK* 


Ik 


BOTTIODT 


INC* 


3k 


PRESIDHT 


IFR* 


Ik 


BOTTIBLD 


COM* 


16k 


BOTTIPLY 


IQC* 


5k 


PRESIDHT 


IPL* 


10k 


BOTTIBID 


DQC* 


14k 


BOTTIPTR 


nc* 


3k 




DOC* 


2k 


BOTTIBLD 


DSC> 


Sk 


BOTTI STR 


INC* 


3k 


USQ 


COM* 


2k 


BOTTIBLD 


PAS* 


Ilk 


CRC 


COM* 


3k 









Sixth place in the Pascal Runoff goes to Ernest Adams for BOTTICELLI, 
a game in which you think of a person's name and the computer tries to 
guess it. Be fair now, don't use your Aunt Aenes. 

K-41 

EXPRESS 1.01 TEXT EDITOR 

41-DISK DOC* Ik 
CRC COM* 3k 
CRCKLIST CRC* Ik 
D COM 3k 
E COM* 19k 

EXPRESS This is the pubhc domain version of the Stump Brothers' full 

screen text editor. 

ROFF is the classic text formatter. 



ECONTIGl 


COM* 


12k 


TERM 


DAT* 


14k 


EXPRESS 


OVL* 


Sk 


USQ 


COM* 


2k 


EXPRZSSl 


DQC* 


57k 








R0FF4 


CCM* 


31k 








R0FF4 


DOC* 


34k 









U.S. Canada/Mexico Europe/Other 

Software Disks (CAtax) add these shipping costs for groups of 3 disks ordered 
MicroC Disks are $6.00ea +$1.CX) +$1.00 +$1.25 +$1.50 +$2.50 
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Regular Feature 



Computer Corner 



Editorial Comment 
Parting Words 



By Bill Kibler 



Well it seems that after all the other 
work in putting TCJ together, 1 am also 
suppose to write my regular column. 
Strange as it may seem 1 in fact even 
have information for it as well. 

GIVE ME A BREAK.... 

The break I am looking for in this col- 
umn is not related to doing TCJ, but to 
some mail I received the other day. Seems 
this group gave out a support award to 
Microsoft. The group is "Software Sup- 
port Professional Association' ' and the 
award was for "High Call Volume". 
Seems Microsoft handles 35,000 (yup 
thousand) calls every DAY! 

Now give me a break here, you can get 
an award for having software so bad that 
35 thousand people a day have to call 
you. Hasn't Microsoft ever hear of mak- 
ing manuals so people can use them 
instead of calling. Actually having used 
many of their manuals, the problem most 
likely is the fact that the software doesn't 
work like the book said it would. The 
flip side is that the user proably found 
another bug and is calling to find out 
what they Microsoft intends to do about 
it (or not do). 

Personally if I had a product that re- 
quired that much support every day, it 
wouldn't take me long to figure I had 
more problems than I was solving. Cer- 
tainly makes you think there are a lot of 
unhappy users out there, that given half 
a change to use something else would 
jump at it. This fact also reinforces my 
belief that if you really want to learn 
about software and hardware, don't do it 
on a PC, unless you want to be one of the 
35,000 callers. 



LANs 

My data communications course is over 
till next fall and that gives me a chance 
to check out new information. My stu- 
dents were evenly split between needing 
MODEM and LAN technology. The MO- 
DEM part went very well, althought 
many students found their understand- 
ing of the hardware and software rela- 
tionships involved a bit lacking. That 
was very clear when we tackled the LAN 
information. 

It seems that LAN operations are still a 
mysterious box and work by some sort of 
black magic. My course did better than 
most, because I laid it out with t he idea 
that all fiindamentals would be covered 
using MODEMS as the instructional 
medium. Lets face the facts, LANs are 
but an outgrowth of MODEM technol- 
ogy. LANs have control software that 
talks to device drivers that talk to me- 
dium which carries the signals to the 
opposite end. The layers of software and 
hardware are really not that different 
between LANs and modems, yet most 
students are lost once you say LAN. 

After the course work I started checking 
out cheap LAN systems again, especially 
for the older CP/M systems. I did talk to 
the people at $25 network to see if their 
serial LAN software would be portable 
to CP/M. The answer was a ' 'most likely 
NOT." That means we will still need to 
contact other vendors for crossover prod- 
ucts. 

1 understand that Artisoft had an early 
product using Z80 controllers for the 
LAN interface cards. It might be possilbe 
that their earlier software could be had 
and ported to our machines. Maybe this 
is going the wrong direction as well and 



an older lower technology approach is 
needed. 

XEROX X.25 

On one of the older disks in SIG/M is an 
X.25 software driver for the Xerox 820 
computers. I have it around here and 
have tried it. This is on SIG/M 238 and 
you can get it from Elliam Assoc, or 
your regular SIG/M BBS or supplier. 

I am not sure about all the ins and outs 
of the program. 1 do remember that all 
the Z80 source code was provided. This 
might make a good source for some 
networking software. In fact any ma- 
chine with a Z80 SIO chip can be usd for 
HDLC communications (which is the 
basis for X.25). These all same XEROX 
820's are the hardware behind many of 
the HAM radio packet systems. I tried to 
make mine do all the HAM stuff but was 
unable to get my 7910 single chip mo- 
dem device to work properly. I think too 
many things came up and therefore I 
didn't get back to find out what went 
wrong. I believe the ARRL Handbook 
now has the schematic and guidelines 
for doing it yourself 

One of the reason for interest in this area 
is a friends desire to do a low cost printer 
network. Actually all his needs are is 
being able to hook up two computers to 
one lazer printer. A main desire is not to 
run cable through walls. I keep thinking 
about a cheap radio transmitter and 
reciever combination ala packet radio. 
Hopefully my next project will be along 
those lines. 

Speaking of lines, looks hke I have run 
out for now. Till later, keep HACKING! 
Bill Kibler 
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Z80 STD USERS! 

Cost Effective Upgrade 

Clock Speeds to 10 MHz 

1 Mbyte On-board Memory 

Increase your system performance and reliability 
while reducing your costs by replacing three of the 
existing cards in your system with one 
Superlntegrsted Z80 Card from Zwick Systems. 

A Superlntegrated Card in your system protects your 
software investment, requiring only minor changes to 
your mature Z80 code. You can increase your 
processing performance by up to 300 percent in a 
matter of days! 

Approximatly 35 percent of each Superlntegrated 
Card has been reserved for custom I/O functions 
including A/O, D/A, Industrial I/O, Parallsl Ports, Serial 
Ports, Fax and Data Modems or almost any other 
form of I/O that you are currently using. 

Call or Fax today for complete information on this 
exciting new line of Superlntegrated Cards and 
upgrade your system the easy wayl 

ZwicK Systems Inc. 

Tel (613) 726-1377, Fax (613) 726-1902 



